Discussion :

[marot_r]

Bonjour à vous.

J'ai une appli où je ne fais qu'ajouter des données dans une table existante. Copiant des données de Excel (compliqué) à Access (plutôt simple).

Mon appli se met à ralentir considérablement au milieu du traitement, même si les tests unitaires ont des temps d'exécution acceptables.
J'ai mis en place du code pour lutter contre le gonflement de la dorsale et de la frontale car je pensais que c'était son poids qui la ralentissait.
Mais je constate qu'entre ces points de compactage, ce n'est pas super-super.

Je me demandais si quelqu'un avait fait un test comparatif entre dbOpenForwardOnly + dbAppendOnly vs dbOpenDynaset pour ce qui est de la vitesse d'exécution ?

A+

[marot_r]

Bonjour.

J'ai trouvé ceci : https://sourcedaddy.com/ms-access/object-methods.html

et finalement je ne pense pas que cela fasse un vrai différence.

D'abord dbOpenForwardOnly est de type Snapshot donc non modifiable donc non adapté à mon cas.
Ensuite dbAppenOnly s'applique à des recordsets dbOnpenDynaset pour ce qui m'intéresse et donc ses performances doivent être proche.

A+

[Pierre Fauconnier]

Salut.

Je dirais bien qu'il faudrait essayer, mais a priori, je pense que les différences résident principalement dans la sécurité. A mon idée, mais je ne suis pas spécialiste, dbAppendOnly a été prévu pour permettre de soulager le moteur qui doit mettre moins de verrous que lorsque tu es dans un mode qui permet la modification. Ca pourrait donc être un peu plus rapide.

Question: Pourquoi utilises-tu DAO? Par quelle méthode injectes-tu les données dans ta table? Recordset.AddNew? Une requête action? Une requête sql construite en VBA?

Perso, je serais tenté de dire que le plus rapide et le moins gourmand est une requête Insert Into soit en texte soit en "procédure stockée" en ADODB...

A tester, mais sans voir ton code, je ne sais pas dire grand chose de plus.

dbOpenForwardOnly n'est qu'en lecture, je pense.

[marot_r]

Bonjour.

dbOpenForwardOnly n'est qu'en lecture, je pense.

Oui c'est ce que j'ai trouvé aussi.

Pour les tests je suis d'accord mais comme mon traitement est TRÈS long et qu'il tourne actuellement … donc pas maintenant. J'avais espéré capitaliser sur l'expérience d'un autre :-).

Pour les ajouts j'utilise un Addnew de DAO avec plein de code conditionnel sur les champs que je modifie ou pas donc transformer cela en SQL me tente moyennement. Je suis de Access à Access (en fait de Access à Access à Access mais c'est juste une astuce pour éviter de frapper le 2Go dans la frontale). De plus j'ai lu que les requêtes "ad-hoc" non enregistrées n'étaient pas les plus rapides car Access doit les interpréter à chaque fois sans pouvoir les optimiser.

Pour info, MA table principale (env 300000 enr) a aussi une vingtaine de tables en relation (modèle en étoile) et ces tables sont "petites" (env 100 enrs par tables).

A+

[Pierre Fauconnier]

Avec Adodb, j'injecte dans Access via des requêtes action Insert Into paramétrées. Même sur des grosses tables, ça n'a jamais posé de problèmes particuliers de lenteur. Mais tout cela est très relatif... Ce qui me semblera +/- rapide pourra te sembler très long.

Cela dit, si ta structure en étoile est bourrée d'intégrité référentielle, ça va ralentir. Peut-être pourrais-tu essayer d'optimiser tes index en supprimant ceux qui sont inutiles. Ca, pour de l'append sur de grandes tables, ça me semblerait pouvoir être un levier, car Access doit mettre ses index à jour au moment de l'append, et plus la table est grosse, plus sa table d'index va être lourde à manipuler.

[marot_r]

Oui j'ai autant de relations d'intégrité que de branches à mon "étoile" et j'en ai besoin.

J'ai seulement une clef primaire (Autonum) et un index unique (autonum + une clef étrangère dont j'ai besoin pour une relation en particulier) sur ma table principale.

Quand je vais avoir le temps je ferai un test en changeant le mode d'ouverture.

A+