Discussion :

[Invit�]

bonjour,

donc voila j'aimerais utiliser le composant TQuery pour lancer des requetes sur ma bdd.
j'aimerais savoir comment pouvoir passer des parametres a mes requetes

merci

[ero-sennin]

Salut !

Dans l'aide de C++ Builder, il y a un exemple mais voici le principe :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
Query1->SQL->Clear();
Query1->SQL->Add("Select * from maBase where Champs=:Condition");
Query1->Params->Items[0]->AsInteger = MonParametre;
Query1->Open();

OU

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
Query1->SQL->Clear();
Query1->SQL->Add("Select * from maBase where Champs=:Condition");
Query1->Params->ParamByName("Condition")->AsInteger = MonParametre;
Query1->Open();

Tu remarqueras que pour passer un param�tre, on utilise les : suivi d'un nom qui te servira si tu utlises le second exemple, sinon, tu utilises le Items... qui lui prends la position de ton param�tre.

Aussi, dans la troisi�me ligne de chacun des codes, tu peux remplacer le AsInteger par un AsString, selon le type du param�tre � envoyer...

Voil�, j'esp�re que c'est ce que tu voulais

[say]

allez, je lance un pav� dans la mare...

A quoi �a sert???
il suffit de faire un replace dans la chaine SQL!!
je pige pas...

[josse95]

Les requ�tes param�tr�es sont surtout utiles si tu les pr�pares avant l'ex�cution (TQuery->Prepare()).

Cela permet de gagner du temps lors de l'ex�cution de la requ�te.

Si tu construis dynamiquement le SQL comme tu le sugg�res, tu ne peux pas pr�parer la requ�te (il faudrait le faire avant chaque ex�cution, ce qui n'aurait aucun int�r�t !).

[ero-sennin]

Excusez du niveau peu �lev� que j'ai en SQL ...

Moi, je cr�e souvent mon SQL dynamiquement mais d'apr�s la remarque de josse95, je me pose maintenant la question � savoir quand pr�parer une requ�te ...
On m'a conseill� d'�crire le SQL en dur dans le code, comme cel�, lors d'un debug, c'est plus clair ... on sait directement ce que la requ�te fait

J'ai fait une petite appli, qui prends des param�tres en compte dans mes requ�tes SQL, mais je ne les pr�pares jamais ! J'�cris ma requ�te, et, je l'utilise juste derri�re.

A quoi �a sert???
il suffit de faire un replace dans la chaine SQL!!
je pige pas...

Je vois pas trop ta m�thode

[say]

Je n'ai moi non plus, jamais approfondi la notion consistant � pr�parer une requ�te.

La m�thode que j'utilise consiste � avoir une s�quence SQL en dur dans le le code mais plus g�n�ralement dans mon cas dans un fichier. A chaque fois que je r�cup�re le SQL dont j'ai besoin, j'ai un traitement qui remplace automatiquement un certain nombre de param�tre avec un AnsiReplace par exemple.

[Invit�]

en tout cas pour ma part sa me convient

en attendant j'avais proceder de la maniere suivante :

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
 
   AnsiString requete;
 
   // initialisation
   MaRequeteDeTest->Close();
   MaRequeteDeTest->SQL->Clear();
 
   // construction de la requete
   requete = "SELECT DISTINCT champs1, camps2 FROM table1, table2 WHERE var = ";
   requete += chaine;
   requete += ";";
 
   // ajout de la requete
   MaRequeteDeTest->SQL->Add(requete);
 
   MaRequeteDeTest->Open();

merci pour l'aide

[josse95]

Tout d�pend de la taille de la base de donn�es qu'on manipule et des performances qu'on souhaite avoir.

Pour ma part, j'ai pu voir une nette diff�rence de performances entre les requ�tes pr�par�es et les autres sur une base de donn�es Oracle assez cons�quente. Je n'utilisais pas les TQuery mais directement OCI, cela dit, ce sont les m�mes principes.

Pour manipuler une petite base de donn�es, c'est vrai que rien ne vaut la simplicit�.

[ero-sennin]

Pour manipuler une petite base de donn�es, c'est vrai que rien ne vaut la simplicit�.

Ok! Ca va alors ! Merci de cette r�ponse et � l'avenir, je me poserai la question afin de pr�parer ou non une requ�te.

Merci

[say]

Tout d�pend de la taille de la base de donn�es qu'on manipule et des performances qu'on souhaite avoir.

Pour ma part, j'ai pu voir une nette diff�rence de performances entre les requ�tes pr�par�es et les autres sur une base de donn�es Oracle assez cons�quente. Je n'utilisais pas les TQuery mais directement OCI, cela dit, ce sont les m�mes principes.

Pour manipuler une petite base de donn�es, c'est vrai que rien ne vaut la simplicit�.

de vraies diff�rences de performances? �a m'int�resse...

en r�alit�, il se passe quoi lorsqu'on pr�pare la requ�te?

[josse95]

A vrai dire, le gain de performances n'est pas tant li� � la taille de la base de donn�es qu'au nombre de requ�tes que tu ex�cutes.

Pour t'en convaincre.

Fais toi m�me ce test. Avec le module base de donn�es de C++ Builder, cr�e une table Paradox � deux champs (le premier de type Integer (et index primaire), le deuxi�me de type A(20) (index secondaire unique));

1er test, code ex�cut�:

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
        char s[80];
        time_t t0;
 
        Query1->Close();
        Query1->SQL->Clear();
        Query1->SQL->Add("Insert into test values(:Index,:Valeur)");
        Query1->Prepare();
 
        t0 = time(0);
        for (int i=1;i<50000;i++)
        {
                Query1->Params->Items[0]->AsInteger = i;
                Query1->Params->Items[1]->AsString = IntToStr(i);
                Query1->ExecSQL();
        }
        Query1->UnPrepare();
        sprintf(s,"%d sec",time(0)-t0);
        ShowMessage(s);

R�sultat: 3 sec

2�me test:

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
        char s[80];
        char sql[80];
        time_t t0;
 
        Query1->Close();
 
        t0 = time(0);
        for (int i=1;i<50000;i++)
        {
                Query1->SQL->Clear();
                sprintf(sql,"Insert into test values(%d,'%d')",i,i);
                Query1->SQL->Add(sql);
                Query1->ExecSQL();
        }
        sprintf(s,"%d sec",time(0)-t0);
        ShowMessage(s);

R�sultat: 175 sec

Pour les deux tests, je suis parti du m�me �tat initial de la table (table vide).

Si �a, ce n'est pas probant !