Discussion :

[Christophe Charron]

Bonjour,
je ne sais pas si l'intitulé de ce post est correctement formulé alors que le corps sera plus parlant et que vous pourrez me renseigner.

Lorsque je trace des requêtes, parfois, l'intitulé de la requête est de forme

Code :

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

DELETE from latable where laclef=1

et parfois

Code :

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

(@1 tinyint) delete latable where laclef=@1

La très grande majorité des traces est du première modèle et comme en mode débug, je préfixe mes requêtes d'un commentaire indiquant l'origine programmatique de la requête, je n'ai aucun mal à m'y retrouver dans les programmes.
Par contre, la seconde me pose problème car je n'arrive pas à en déterminer l'origine. Je note qu'il n'y a pas le "from" dans le texte de la requête et j'en déduis que cela ne vient pas "directement de mon programme".
Sur cette table, je n'ai pas, a priori, de trigger et encore a priori, aucune fonction ou procédure SQL liée à de mon application ne fait de suppression dans cette table.

D’où cela peut-il provenir ?
Comment investiguer pour retrouver l'origine de la requête ? Un script hors tout ?

D'avance, merci de vos lumières et de vos pistes.

[SQLpro]

La présence de "(@1 tinyint)" montre que la requête a été paramétrée... Du fait qu'elle est revenue plusieurs fois, SQL Server l'a paramétrée afin de mettre en cache un seul plan d'exécution realtif à toutes les exécutions.

Si vous voulez retrouver dans vos programmes ou se trouvent vos requêtes, le moyen le plus efficace est de les documenter de manière interne au texte de la requête. Pour ma part j'utilise un GUID unique pour chaque requête écrite, situé juste après le mot clef SELECT, INSERT, UPDATE, DELETE ou MERGE.

Exemple :

Code :

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

DELETE /* 9620FBC8-DD7F-49D8-96FB-2096CA2167B7 */ from latable where laclef=1

Après pour rechercher dans quel coin du code se trouve cette requête, faire un GREP sur les fichiers sources applicatif et une requête dans les routines de la base...

Pour ce dernier, au niveau des routines du serveur, faire :

Code :

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

1
2
3
SELECT * 
FROM   sys.server_sql_modules 
WHERE definition LIKE '%9620FBC8-DD7F-49D8-96FB-2096CA2167B7%'

Au niveau des routines de toutes les bases, faire :

Code :

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

EXEC sp_MSforEachdb 'SELECT ''?'' AS DBNAME, * FROM sys.sql_modules AS m JOIN sys.objects AS o ON m.object_id = o.object_id JOIN sys.schemas AS s ON o.schema_id = s.schema_id WHERE m.definition LIKE ''%9620FBC8-DD7F-49D8-96FB-2096CA2167B7%'''

A +

[Christophe Charron]

Merci beaucoup pour ces précisions.
En mode "débuggage verbeux", je retrouve mes requêtes, lorsque les traces reflètent l'écriture dans source en insérant entre autres données, en tête de requête et en commentaire, la pile des appels du code précédant l'appel de la méthode d'exécution de la requête, plus l'identifiant de l'utilisateur, le nom et la version de l'applicatif. J'ai ainsi des informations de contexte qui me permettent parfois d'obtenir des informations non dites par l'utilisateur.

Je profite de la conversation pour vous demander si deux requêtes

Code :

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

1
2
3
4
5
6
7
/*
Mon applicatif
Version 1.0
Pile des appels :
FenetreMenu.pf_init.op_metier:f_lireconfiguration Ligne 20
*/
select parametre from param where cleparam=10

et

Code :

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

1
2
3
4
5
6
7
/*
Mon applicatif
Version 1.0
Pile des appels :
FenetreMenu.pf_init.op_metier:f_lireconfiguration Ligne 35
*/
select parametre from param where cleparam=20

sont considérées par SQL Server comme identiques, donc mises en cache, donc utilisant un seul plan d'exécution.
En fait, ce qui est commenté dans une requête est-il considéré comme changeant le "sens" de la requête, pour SQL Server ?

D'avance, merci pour votre éclairage

[SQLpro]

Votre commentaire étant situé avant le début de la requête sera expurgé du texte de ladite requête.

En revanche le fait que la valeur du paramètre est différent (10, 20) peut entrainer un changement de requête.

A +

[Christophe Charron]

Merci.