Discussion :

[Didier100]

Delphi 7 - Windows XP -SP2 - Base de données MS Accèes 2003

Dans mon dernier programme j'ai constaté une extrême lenteur au passage du code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
for i := 1 to (lines - 1)do begin
 
// ..... pas mal de code .......
 
  AdoQuery1.SQL.Add('UPDATE DOSSIER SET PROVENANCE_PERFEO=' + '''' + PROVENANCE_PERFEO + ''''  +  'WHERE ID_ORDER =' + '''' + ID_ORDER +  '''' + ';');
 
  try
    AdoQuery1.ExecSQL;
  except
    // .... code gestion des éventuells erreurs ....
    Exit;
  end;
 
end; //for....

En fait la lenteur apparaît exactement à la ligne:

Code :

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

AdoQuery1.ExecSQL;

Si j'ai une centaine d'enregistrements je doit attendre quelques minutes pour mettre ma base de données (MS Accès) à jour (5 sécondes en moyenne par enregistrement)! Pour un simple UPDATE c'est vraiment trop lent!

J'avais pense à regrouper les requettes dans un fichier via la fonction SaveToFile ..... mon fichier resemblait à ceci (extraît de fichier test.sql ):

UPDATE DOSSIER SET PROVENANCE_PERFEO='SOURCE INCONUE'WHERE ID_ORDER ='f6717df0f6caf4ae929753b90dfcfe90';
UPDATE DOSSIER SET PROVENANCE_PERFEO='SOURCE INCONUE'WHERE ID_ORDER ='2420844a1bd6f7ccafbde04eb6f87c3d';
UPDATE DOSSIER SET PROVENANCE_PERFEO='SOURCE INCONUE'WHERE ID_ORDER ='32d21c5dca60dc4139ad4fab55a1b406';
UPDATE DOSSIER SET PROVENANCE_PERFEO='SOURCE INCONUE'WHERE ID_ORDER ='578330936803ba90a682aae01679caf2';
UPDATE DOSSIER SET PROVENANCE_PERFEO='SOURCE INCONUE'WHERE ID_ORDER ='b67b086ae7eabb286a90aff30535fad6';

etc ... et de faire passer les requettes en une seule fois ..... c'est à dire:

Code :

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

1
2
AdoQuery1.LoadFromFile('C:\test.sql'); 
AdoQuery1.ExecSQL;

mais cela me génère un message d'erreur disant; Qu'il y à du code en fin d'instruction SQL .... Donc je ne sais pas comment me prendre pour faire passer la "pillule" c'est à dire d'executer tous les requettes d'update via la Fonction LoadFromFile?

Je suis ouvert à toutes les propositions permettant l'accelaration des requettes via UPDATE .....

Merci d'avance pour votre aide.

[Rayek]

Etrange, j'utilise assez souvent ACCESS 2003 et je ne rencontre pas ce problème de lenteur.

Est ce qu'il y a un index sur le champ ID_ORDER ?
La table a-t-elle beaucoup d'enregistrement ?
Est ce que des paramètres de base du composant AdoQuery1 ont été modifiés ?

[Didier100]

Bonjour Rayek,

Merci pour ton aide ....voici les réponses à tes questions.

Est ce qu'il y a un index sur le champ ID_ORDER ?

Non, l'index est sur le champ DOS_ID .

La table a-t-elle beaucoup d'enregistrement ?

Il y à environ 35000 enregistrements dans la base de données (fichier .mdb qui pèse 47,5 MO).

Est ce que des paramètres de base du composant AdoQuery1 ont été modifiés ?

Non je n'ai pas modifié les paramètres de base d'AdoQuery.

[guillemouze]

Non, l'index est sur le champ DOS_ID .
(...)
Il y à environ 35000 enregistrements dans la base de données (fichier .mdb qui pèse 47,5 MO).

une requete sur du texte sera toujours plus lente que sur des nombres. Ne peux tu pas faire tes requetes avec un WHERE sur des entiers?

sinon essaye de mettre ID_ORDER en index (pas en clé, juste en index, je pense que c'est possible avec access)

as tu essayé d'executer ta requete directement dans access pour comparer le temps (qui doit etre sensiblement le meme pour un UPDATE)?

[philnext]

Je ferais aussi le même conseil, ne peux tu transformer ton ID_ORDER en integer ?

[Didier100]

GRAND MERCI pour vos réponses guillemouze et philnext.

Le format du champs ID_Order peut évoluer ... c'est pas vraiment moi qui à la main sur le format .... Nous importons des données provenant d'une autre société qui identifié chaque fiche client par des clés du type exemple "f6717df0f6caf4ae929753b90dfcfe90" .... je ne le sent pas trop de transformer cette clé en integer ... Je ne connaît pas le codage de la clé .... comme les lettres ne dépassent pas le "F" ont pourrait y dire que c'est du hexadécimal ...
Bref ...

J'ai préféré de creuser la deuxième piste

guillemouze à écrit:

sinon essaye de mettre ID_ORDER en index (pas en clé, juste en index, je pense que c'est possible avec access)

et cela à fait merveille .... les cent enregistrement sont importe en moins de 5s avec un Indexé = Oui - Sans doublons !!!!! Je retrouve enfin mon sourire.

Encore MERCI pour votre aide

[Rayek]

GRAND MERCI pour vos réponses guillemouze et philnext.

Le format du champs ID_Order peut évoluer ... c'est pas vraiment moi qui à la main sur le format .... Nous importons des données provenant d'une autre société qui identifié chaque fiche client par des clés du type exemple "f6717df0f6caf4ae929753b90dfcfe90" .... je ne le sent pas trop de transformer cette clé en integer ... Je ne connaît pas le codage de la clé .... comme les lettres ne dépassent pas le "F" ont pourrait y dire que c'est du hexadécimal ...
Bref ...

J'ai préféré de creuser la deuxième piste

guillemouze à écrit:

et cela à fait merveille .... les cent enregistrement sont importe en moins de 5s avec un Indexé = Oui - Sans doublons !!!!! Je retrouve enfin mon sourire.

Encore MERCI pour votre aide

En général, les lenteurs peuvent être régler par l'ajout d'un index sur un champs (d'où la première question non anodine de ma première réponse )

Sinon, vu que ton problème est résolu pense à cliquer sur