Rapidité Update : Direct VBA ou appeler La requete ??

**samlepiratepaddy** · 30/09/2005, 14h04

Slt,
Une question me travaille

Quel est la sulution la plus rapide :
Entre Une Requete UPDATE classique faite avec l'interface Accèss et ensuite sur une action faire appele a elle en VBA en la nomant
Du style

DoCmd.OpenQuery....

Et Cette même requete mais construite dans le VBA avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DoCmd."UPDATE Table SET Table.Champ.........Where .....

Ma question est en relation avec une UPDATE pas trop longue (6 ou 7 champs a mettre a jour ) mais executée plus de 3000 fois par jours !
Déja y a t-il une différence ?
Si oui , quelle est la solution la plus optimum ?

PS: mes requetes fonctionnent très bien mais pas encore fait de test multi postes et surtout répété autant de fois dans une journée

Merci d'avance

**petitmic** · 30/09/2005, 14h15

j'ai déjà essayé les deux méthodes, et j'ai l'impression qu'une requête faite à la première solution est plus rapide que la seconde.

**fdraven** · 30/09/2005, 14h27

L'appel d'une requête déjà enregistrée est plus rapide que de faire un docmd.runsql "SELECT....."

**cafeine** · 30/09/2005, 15h20

j'ai voulu en avoir le coeur net ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
benchmarkupdate
Exécution par CurrentDB.Execute : 7,063 s
Exécution par DoCmd.RunSQL : 8,891 s
Exécution par RECORDSET : 6,953 s
Exécution par REQUETE enregistrée : 8,609 s

Voici le code des tests :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
Function BenchMarkUpdate()
 
Dim t0 As Single, t1 As Single
Dim rst As DAO.Recordset
Dim i As Long
 
t0 = Timer
For i = 1 To 2000
    CurrentDb.Execute "UPDATE [Clients] SET [TestInt] = 12 WHERE [nom] = 'La Poste';"
Next i
t1 = Timer
Debug.Print "Exécution par CurrentDB.Execute : " & Format(t1 - t0, "0.000") & " s"
 
t0 = Timer
For i = 1 To 2000
    DoCmd.RunSQL "UPDATE [Clients] SET [TestInt] = 12 WHERE [nom] = 'La Poste';"
Next i
t1 = Timer
Debug.Print "Exécution par DoCmd.RunSQL : " & Format(t1 - t0, "0.000") & " s"
 
t0 = Timer
strCrit = "[nom] = 'La Poste'"
For i = 1 To 2000
    Set rst = CurrentDb.OpenRecordset("SELECT [TestInt] FROM [Clients] WHERE [nom] = 'La Poste';", dbOpenDynaset)
    rst.MoveFirst
    Do Until rst.EOF
        rst.Edit
        rst!TestInt = 12
        rst.Update
        rst.MoveNext
    Loop
Next i
t1 = Timer
Debug.Print "Exécution par RECORDSET : " & Format(t1 - t0, "0.000") & " s"
 
t0 = Timer
For i = 1 To 2000
    DoCmd.OpenQuery "qryUpdate"
Next i
t1 = Timer
Debug.Print "Exécution par REQUETE enregistrée : " & Format(t1 - t0, "0.000") & " s"
 
End Function

DAO est vraiment trop fort !!!

**Tofalu** · 30/09/2005, 15h37

Tu peux comparer avec ado cafeine ?

Par contre ma méthode préférée restera quand même celle là :
Exécution par CurrentDB.Execute : 7,063 s

Bien plus propre je trouve

**samlepiratepaddy** · 30/09/2005, 21h45

Slt du soir,

Merci de toutes ces réponses !!!
J'étais absent et j'ai pas pu suivre en direct !
Mille excuses !

Vraiment fort les gars !

Bon et bien évidement, c'est la requete que je ne fais jamais qui est plus rapide

reste plus qu'a mettre ça en place !
J'y vais me confronter au ... comment déja...

CurrentDb.OpenRecordset

ben c'est pas gagné s't'affaire !!

Merci à tous et @+

**cafeine** · 30/09/2005, 22h43

Envoyé par samlepiratepaddy

Slt du soir,

Merci de toutes ces réponses !!!
J'étais absent et j'ai pas pu suivre en direct !
Mille excuses !

Vraiment fort les gars !

Bon et bien évidement, c'est la requete que je ne fais jamais qui est plus rapide

reste plus qu'a mettre ça en place !
J'y vais me confronter au ... comment déja...

CurrentDb.OpenRecordset

ben c'est pas gagné s't'affaire !!

Merci à tous et @+

Le Benchmark était informatif, ne pas prendre ces mesures pour des valeurs absolues, en terme de programmation je te conseille DoCmd.RunSQL qui se code en UNE ligne puisque l'écart reste faible sur 2000 requêtes.

**samlepiratepaddy** · 01/10/2005, 09h25

Slt cafeine,
Je rejoins ton avis

Et surtout, étant donné que la requete concernée met a jour 7 champs nous parlons ici de milisecondes de différence !
Certe, utilisée X fois par jour mais une fois a chaque fois

Mais merci d'avoir éclairé ma lanterne sur le sujet !
Cela servira aussi pour tout ceux qui "encode" dur

, maintenant ils ont des valeurs à mettre en face, non plus des hypothèses !
j'opte pour le DoCmd.RunSql......
Merci de tes conseils avisés !!

@+

**Tofalu** · 01/10/2005, 09h53

Par contre cafeine, y a quand même un soucis dans ton banc d'essai...

For i = 1 To 2000
CurrentDb.Execute "UPDATE [Clients] SET [TestInt] = 12 WHERE [nom] = 'La Poste';"
Next i

Tu crées 2000 instances de nouveaux objets DAO.Database ce qui bouffe de la RAM pour rien... On aurait encore des valeurs encore meilleures pour DAO en utilisant un seul objet DB

**Tofalu** · 01/10/2005, 10h14

Je viens de tenter un test sur plus de 150 000 lignes ...

Exécution par CurrentDB.Execute : 3,359 s
Exécution par ADODB.Execute : 3,406 s
Exécution par DoCmd.RunSQL : 5,469 s
Exécution par DAORECORDSET : 24,266 s

Quant au recordset ADO, il bloque du fait que je dépasse le nombre de vérous autorisés

**FRED.G** · 01/10/2005, 10h30

Tof, peux-tu tester ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
dim qdf as doa.querydef
set qdf = currentdb.querydefs!
UneRequEnregistréeParamétréesCorrectementEtIndexée
For i = 1 To 2000
  qdf.parameter("para1") = 12
  qdf.execute
Next i 
set qdf = nothing really matter  ;-)

Et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
dim qdf as doa.querydef
set qdf = currentdb.querydefs!
UneRequEnregistréeParamétréesCorrectementEtIndexée
For i = 1 To 2000
  qdf.parameter("para1") = i
  qdf.execute
Next i 
set qdf = nothing really matter  ;-)

**FRED.G** · 01/10/2005, 22h38

Tof ?

**Tofalu** · 01/10/2005, 22h42

Envoyé par FRED.G

Tof ?

J'ai rien compris à ta demande mon pauvre fred

**FRED.G** · 01/10/2005, 23h07

Ben laisse tomber mais tu as testé différentes solutions d'exécution de requetes :

Exécution par CurrentDB.Execute
Exécution par ADODB.Execute
Exécution par DoCmd.RunSQL
Exécution par DAORECORDSET

Et je te demandais de tester également les deux que j'ai proposé... c'est tout.

C'est ça que tu n'as pas compris ?
UneRequEnregistréeParamétréesCorrectementEtIndexée

**Tofalu** · 01/10/2005, 23h11

UneRequEnregistréeParamétréesCorrectementEtIndexée

Oui

**FRED.G** · 02/10/2005, 00h02

Je pensais que currentdb.querydefs! ne laisserait aucun doute dans ton esprit sur le fait qu'on ne puisse pointer que vers une requête enregistrée.

D'où le UneRequEnregistréeParamétréesCorrectementEtIndexée

Ensuite, cette requête enregistrée doit comporter au moins un paramètre servant à indiquer la valeur à mettre à jour...

En fait, il concrêtement il faudrait plusieurs paramètres et au minimum deux :
1 pour chaque valeur à mettre à jour.
1 pour chaque valeur servant de critère et devant pouvoir changer dynamiquement :

Concrêtement pour reprendre l'exemple de caféine :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CurrentDb.Execute "UPDATE [Clients] SET [TestInt] = 12 WHERE [nom] = 'La Poste';"

ça donne un paramètre pour le champ [TestInt] et un pour le champ [nom]

Et je pensais que ceci serait une évidence pour toi, donc je me suis contenté d'écrire :
UneRequEnregistréeParamétréesCorrectementEtIndexée

Enfin l'intérêt d'utiliser des requêtes enregistrées est de profiter du Rushmore, qui optimise je pense l'utilisation des indexs.

Donc moi j'aurais bien vu un index sur le(s) champ(s) du critère à savoir dans notre exemple : [nom]

Et je pensais que ceci était de la routine pour toi aussi donc j'ai seulement écrit : UneRequEnregistréeParamétréesCorrectementEtIndexée

Je voulais juste ne pas perdre de tempsà rédiger du code complet pour n'importe quel exemple, compte tenu du fait que je ne connaissais pas le sql de ta requête de tests à toi et qu'à mes yeux tu comprendrais ces banalités dès la première lecture.

Mais bon, comme quoi...

**Tofalu** · 02/10/2005, 00h10

Tu me cherches là ...

Déjà ton post a perdu en crédibilité avec seulement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set qdf = nothing really matter  ;-)

Je pensais que currentdb.querydefs! ne laisserait aucun doute dans ton esprit sur le fait qu'on ne puisse pointer que vers une requête enregistrée.

Ben oui mais je voyais pas de quelle requête tu parlais

Et ça tombe à l'eau parce que ma table de test ne comprte qu'un seul champ clé primaire donc forcément l'effet rushmore en prend un coup lol

Mais je reteste tout ça dans le week end sur une table plus petite histoire d'avoir un comparatif ADO.Rst aussi et avec plus de champs

**FRED.G** · 02/10/2005, 01h03

Envoyé par Tofalu

Tu me cherches là ...

Ben vi ! Puisque tu ne m'as pas trouvé !

Mais je reteste tout ça dans le week end sur une table plus petite histoire d'avoir un comparatif ADO.Rst aussi et avec plus de champs

Si tu fais ça sérieusement, je pense qu'on pourra le mettre de côté pour un (future) section tests & bancs d'essai, ça nous ferait 2 trucs intéressants avec formule1

...

**cafeine** · 02/10/2005, 11h17

Tofalu, très bon complément à mon benchmark vite fait, peux-tu nous donner le code de ce banc d'essai à titre informatif ? je pense que ça pourrait en intéresser certains.

Rapidité Update : Direct VBA ou appeler La requete ??

Access

Discussions similaires

Partager

Partager