Discussion :

[exyacc]

bonjour,

voila je fais une requete avec des parametres (ADOquery, MSSQL2000) sous delphi 2006 comme ceci

Code sql :

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

INSERT INTO transacs ([Transaction Number]) VALUES (:_transac_id)

Code :

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

 _Query2.Parameters.ParamByName('_transac_id').value:=2;

je voulais savoir s'il y avait moyen de recuperer la requete avec les parametres remplacés ? car si je fait _query2.text j'ai

Code sql :

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

INSERT INTO transacs ([Transaction Number]) VALUES (:_transac_id)

alors que j'aimerai recuperer :

Code sql :

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

INSERT INTO transacs ([Transaction Number]) VALUES (2)

pour le sauvegarder dans un fichier texte....

une idee ?

merci

[Just-Soft]

Salut;

utilise la propriétés Params, c'est une liste des paramètres passés à ta requête, elle a commence par zéro. Le paramètre 1 est Params[0] ainsi de suite.

Bonne chance.

[chaplin]

Code :

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

INSERT INTO transacs ([Transaction Number]) VALUES (:_transac_id)

Les commandes SQL sont parsées à partir de la propriété SQL (TStrings) du composant.
Côté client, le composant se chargera de repérer les paramètres s'ils existent et de créer la liste des paramètres en conséquence.
S'il y a des paramètres dans la requête, la requête va être préparée sur le serveur de telle sorte à recevoir un ou plusieurs paramètres.
Cette méthode est interessante pour une insertion massive d'enregistrement car la requête est préparée une seule fois sur le serveur.

Si la requête SQL est écrite de façon litérale comme suit:

Code :

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

INSERT INTO transacs ([Transaction Number]) VALUES (2)

La préparation de la commande va demander plus de temps car l'instruction devra être interprétée en totalité à chaque fois contrairement à la requête paramétrée.
En conclusion, la commande SQL (TStrings) va être interprêtée (Prepare) une seule fois sur le serveur sauf si son contenu est modifié par code.

[exyacc]

donc je peux pas recuperer la requete une fois les parametres remplacés ..?
il vaut mieux que j'utilise pas de parametre et j'ecrive directementmes variable dans la requete...

[chaplin]

donc je peux pas recuperer la requete une fois les parametres remplacés ..?

- Oui

il vaut mieux que j'utilise pas de parametre et j'ecrive directement mes variable dans la requete...

- Oui, mais ce sera au détriment des performances, tout dépend du volume d'enregistrement concerné.

Si c'est pour faire un log des commandes passées au serveur, j'utiliserais plutôt l'événement BeforeOpen du composant,
et je récupérais les paramètres de la requête dans le fichier log, pour bien dissocier les process, ça se discute.

[exyacc]

dans le before open, qd je recupere le parametre, j'ai :date ou 30/10/2008 ?

[chaplin]

En fait, il faut utiliser ExecSQL (ie Open=> BeforeOpen ??), pour executer la requête SQL. Je ne sais pas quel composant tu utilises.
L'idée c'était d'utiliser un événement pour capter l'info. Mais s'il s'agit vraiment de faire des tests, je pense qu'il faudrait s'orienté vers DUnit.
Je ne l'ai jamais mis en pratique, mais ça doit valoir le coup.

J'ai pas beaucoup d'infos sur tes intentions, donc difficile de fournir une réponse claire.

[Franck SORIANO]

Comme on te l'as dit, ce que tu veux faire n'est pas possible directement.
Lorsque tu définis une requête paramétrée, elle est soumise tel quel au serveur (enfin dans ton cas pas tout à fait, car pour ADO les paramètres doivent être indiqués avec "?" à la place de ":NomDuParam", le TADOQuery fait le remplacement automatiquement).
Les valeurs des paramètres sont transmis séparéments au SGBD, donc la requête n'est jamais remise en forme pour remplacer les paramètres par leur valeur.
Pour ce que tu veux faire, tu dois le faire toi-même.

La préparation de la commande va demander plus de temps car l'instruction devra être interprétée en totalité à chaque fois contrairement à la requête paramétrée.

C'est la théorie qui est toujours présentée avec les SGBD. Mais c'est de moins en moins vrai. Surtout avec SQL Server.
En fait, ce qui prend le plus de temps ce n'est pas d'analyser la requête mais de calculer son plan d'exécution optimal (je ne parle pas de la phase d'exécution bien sûr).
SQL Server, tout comme Oracle lorsqu'ils reçoivent une requête non paramétrées sont capables de remplacer automatiquement toutes les valeurs litérales des requêtes par des paramètres (ils transforment la requête en requête paramétrée automatiquement) pour calculer le plan d'exécution une fois pour toute et le garder en cache pour qu'à la requête suivante, il puisse être réutilisé même si la requête n'est pas paramétrée et que ces valeurs litérales changent.

Au final, avec SQL Server, préparer une requête avant de l'exécuter ne sert à rien (si ce n'est à dégrader les performances).
Les requêtes paramétrées permettent néanmoins d'optimiser un peu les performances car les valeurs des paramètres sont transmises au serveur sous formes binaires et non plus textuelles (donc réduction de traffic réseau, surtout si on est en unicode).

Cependant, paramétrer les requêtes reste une bonne pratique, nottamment au niveau sécurité (on évite les risques d'injection SQL) et typage des données.