Discussion :

[Simplifi]

Hello
Je suis en train de chercher quelle méthode est la plus rapide pour mettre à jour certains enregistrements? à partir de VBA j'ai le choix entre:
- exécuter une requête enregistrée
- exécuter du SQL où j'ai bien pris soin de remplacer les noms de paramètres par leur valeur
- charger la sélection qui m'intéresse dans un recordset et le traiter en mode calcul
Avez vous une idée du sujet
PS: je mettrais ici les résultats de ma recherche si je trouve

[minot83]

Salut,
As-tu essayé de comparer les vitesse de traitement en mettant en place la fonction GetTickCount?
http://access.developpez.com/faq/?page=TAProg#tps_exec

bonne journée

[Simplifi]

Merci, oui bien sûr.
j'ai même fait une boucle pour faire 10, 100 ou même 1000 fois la même manip sinon la variabilité ne permet pas de se faire une idée.
Apparemment, l'avantage est à l'une ou à l'autre des solutions suivant les cas.

[Shanur]

A mon avis, pas vraiment de différence, les trois méthodes passeront par SQL, le seule chose qui change est la façon dont le traitement sera lancé.

Pour accélérer le traitement, il vaut mieux passer par l'indexation de la table pour un ou plusieurs des champs utilisés dans la requête.

[Invité]

Bonjour

Je pense que les indications de ce tuto t'aideront : http://loufab.developpez.com/tutorie...sation/#LIII-E

Philippe

[loufab]

Bonjour,

Exécuter une requête enregistrée ou générée dans VBA il n'y a pas de différence significative.

Il peut y avoir une différence selon si les paramètres sont en dur ou s'ils doivent être récupérés dans une table via VBA. Dans ce dernier cas il s'agit simplement du temps qu'il est nécessaire pour résupérer ces paramètres (souvent imperceptible).

Par contre le recordset est nettement plus long sur des gros volumes de données. Ceci est un fait établi.

Enfin il y a la solution ADO, qui pour des moteurs des bases de données externes, type SQL Server, peuvent faire la différence à la condition que la requête ne concerne que des tables de la base de données et non un mélange entre locales (tables Jet) et distantes (Sql Server).

L'indéxation est valable pour toutes les bases de données, attention cependant à ne pas tomber dans les excés et d'avoir l'effet inverse de celui désiré.

Plus d'info dans le tuto indiqué par Philippe.

Cordialement,

[Shanur]

Bonjour,

Il existe aussi la solution de passer par un accès direct sur la table.

J'explique le problème rencontré, il y a pas mal d'année :

Données

un fichier (table) NAL de plus d'un million d'enregistrements.

Id
Nom
Rue
Numéro dans la rue
Numéro de boîte postale
Code postal
Localité

une impression de la table par code postal.
une limite de temps : vingt milles formulaires imprimés par jour (en 10 heures)

Problème

En cas de bourrage de l'imprimante ou en cas de rupture (il s'agit de formulaires en continu) ou de problème de ruban (encre), il fallait pouvoir relancer l'impression avec une limite inférieure.

Solutions

SQL

Relancez l'impression de 2000 enregistrements (contenu d'une boîte de formulaire en continu) en utilisant une instruction WHERE sur le code postal, la rue, le numéro dans la rue et le numéro de boîte postale. Le fichier est indexé sur le code postal. La procédure est lancée en arrière plan avec une priorité basse.

Le résultat s'est fait attendre : plus de 36 heures pour le traitement et comme il s'agissait d'un système multi-utilisateurs, les utilisateurs (interactif, priorité haute) ont vu leur temps de réponse monter au dessus de une minute trente.

Index

Un index est créé sur le code postal, la rue, le numéro dans la rue et le numéro de boîte postale. Le programme se positionne à la limite inférieure sur la table et lit 2000 enregistrements. L'exécution se fait arrière plan avec priorité normale

construction de l'index (une seule fois) : plus de 5 h.
mise à jour de l'index (journalier, en dehors des heures de bureaux) : +/- une heure (varie suivant le nombre de modifications).
temps d'exécution : +/- 5 minutes, temps d'accès normal pour les autres utilisateurs.

Cette solution a permis de réaliser ce qui suit :

impression de X formulaires avec une limite inférieure
impression de formulaires avec une limite inférieure et une limite supérieure.
réalisation de programme de recherche de doublons basé sur l'index.

Une optimisation a été apportée par la suite pour diminuer la place occupée par l'index. La zone rue a été scindée en "type de rue" et "nom de rue". "Type de rue" fait référence à un fichier (Id, Libellé) dont "libellé" pouvait être " rue ", "rue des ", "rue de l'" , etc. Le nombre de critères de recherche est porté à cinq : le code postal, la nom de rue, le type de rue, le numéro dans la rue et le numéro de boîte postale. L'index sur le nom de la rue est limité au douze premiers caractères.

Une dernière optimisation a été réalisée : la création (achat) d'une table comportant tous les noms de rue (Id, code postal, nom, préfixe du nom). Cela a permis le retour à l'index rue mais cette fois sur une zone numérique. Les critères de recherche sont limités à quatre. Malgré la place occupée par la table rue et ses indexes, il y a eu un sérieux gain de place sur le support (disques durs).

Remarques

La solution 1 a été testée lors des débuts de SQL. Les systèmes d'exploitation et SQL ont probablement été améliorés depuis.

Un index prend de la place. Il ne faut pas utiliser la solution 2 pour les petites tables ou si on ne doit pas avoir un temps d'exécution optimum.

La solution 2 peut être appliquée de façon partielle sur le critère le plus limitatif. Par exemple, un index sur une date, les autres critères seront exclus lors du traitement via programmation.

Mon impression est que SQL est limité par le nombre de données à traiter et/ou la puissance du système d'exploitation. Il reste à voir où se situe cette limite. Pour ce faire, vous pouvez créer un formulaire en continu sur une table comportant au moins une zone alphabétique (indexée ou non). Vous ajoutez une zone de recherche dont vous allez exploiter l'évènement "Change" qui aura lieu après chaque frappe dans la zone de recherche. Dans le code de l'évènement, vous ajoutez des conditions limitant éventuellement l'exécution du code (à partir de X caractères dans la zone de recherche par exemple) et un filtre ("zone alpha like " & recherche & "*", par exemple) et l'activation du filtre. Vous pouvez dès lors tester avec ou sans index et avec ou sans limitation du filtre au Xème caractère. Sur mon système et sur cent milles enregistrements, avec filtre sur le premier caractère, c'est l'heure de la pause pipi (comme pour les pubs à la TV).

[Simplifi]

Bonne année à tous!
Voilà la petite base qui m'a permis de tester le sujet:
elle est composée d'une table, d'une requête enregistrée, d'un formulaire avec un peu de VB.
Les résultats sont étonnants et changent suivant les machines mais on a des constantes:
- la requête et le SQL ont un temps de latence important 4 à 6 milisecondes
- le recordset n'en a pas
- par contre la requête et le SQL 'montent' moins vite que le VB en fonction du nombre de lignes modifiées
- je n'ai trouvé aucune incidence du nombre de lignes de la table sur le temps
- le nombre de champs mis à jour n'influe que très peu
- je suis toujours épaté par la rapidité du SQL de vidage de la table, malheureusement, je ne peut répéter l'opération 1000 fois pour obtenir une bonne précision de la mesure, dommage!
Sur mon PC (core i3) il est plus rapide d'utiliser le recordset si on met à jour moins de 100 lignes
Sur un AS400 (je ne connaît pas le processeur) les temps de latence son plus importants 8,7 et 6,6 par contre le recordset est deux fois plus rapide! et le croisement se situe vers 2000 lignes mises à jour.

PS: Pour faire le petit graphique, j'ai utilisé plusieurs fois la base en faisant varier les paramètres.

IN FINE: comme dans mon application, j'utilise beaucoup de requêtes pour ajouter ou mettre à jour une seule ligne, je vais utiliser exclusivement le recordset