Discussion :

[Azurphenix]

Bonjour,
J'ai une procédure stockée qui calcule des statistiques sur des données historisées.
En paramètre elle reçoit la plage horaire pour le calcul et les noms des mesures sur lesquelles le calcul doit être fait.
Tout fonctionne correctement pendant un temps mais, sans message d'erreur spécifique dans les logs, cette procédure ne fonctionne plus.
Quand elle est dans cet état, si je lance le contenu dans un query séparé : les résultats s'affichent sans erreur.
Si j'appelle la procédure => erreur d'exécution et le message laisse supposer que les paramètres ne sont pas pris en compte correctement.
J'ouvre la procédure en modification (par le menu de SQL management) puis j'exécute le ALTER sans faire de modification.
La procédure repart correctement jusqu'au lendemain.
Cela me laisse supposer que c'est la version compilée qui devient corrompue. Mais par quoi?
Quelqu'un aurait-il une piste sur la raison de ce fonctionnement et les endroits où je pourrais investiguer?
merci d'avance

[SQLpro]

À partir de quoi cette procédure est-elle lancée :

• SSMS ?
• Agent SQL ?
• Application développée ? (si oui, avec quel langage / connecteur ?)

A +

[Azurphenix]

À partir de quoi cette procédure est-elle lancée :

• SSMS ?
• Agent SQL ?
• Application développée ? (si oui, avec quel langage / connecteur ?)

A +

Par défaut la procédure est appelée depuis VB.net avec un System.Data.SqlClient.SQLCommand.
mais quand elle tombe, je fait le test d'appel depuis une fenêtre de command query du style "EXEC maProc Param1, Param2, Param3"
Et cela aussi ne passe pas et renvoi l'erreur sauf que l'exécution du code contenu passe bien.
Seule la recompilation relance le bon fonctionnement

Pour information l'erreur est "System.Data.SqlClient.SqlException: Cannot execute the query "SELECT Tbl1010.TagName Col1060,Tbl1010.Value Col1061 FROM Runtime.dbo.History Tbl1010 WHERE Tbl1010.wwRetrievalMode=N'FULL' AND Tbl1010.OPCQuality=(192) AND Tbl1010.DateTime>=? AND Tbl1010.DateTime<=?" against OLE DB provider "INSQL" for linked server "INSQL"."
Or les ? sont sensés contenir les paramètres de date et les Tbl1010 ne correspondent pas aux noms des données : d'où ma déduction que la procédure n'accepte plus les paramètres que ce soit depuis le SQLCommand ou depuis un EXEC directement dans une fenêtre de query.

[hmira]

Le message d'erreur indique l'utilisation des objets serveurs liés.
La requête incriminée référence-t-elle réellement des objets serveurs liés ? Si oui, comment, selon quelle méthode ?
Enfin, peux-tu, en plus du message d'erreur, déjà incomplet, poster le texte intégral de la requête SQL ?

A+

[Invité]

Tbl1010 c'est un alias, la table cible est Runtime.dbo.History.
Est-ce que la bd Runtime existe bien sur ton instance distante ?
Est-ce que le user du linked server a les droits de lire les données de cette table ?

[Azurphenix]

Comme je l'ai indiqué ce n'est pas le contenu qui pose problème car son exécution dans une fenêtre de commande ne génère aucune erreur et retourne bien les données

pour information, la déclaration est "PROCEDURE [dbo].[sp_Statistiques] (@tagname nvarchar(max), @startDate datetime2(7), @EndDate datetime2(7))"
Je ne peux diffuser le contenu complet car il comporte des informations confidentielles.

C'est bien la procédure qui tombe en rideau. l'ouvrir en "ALTER" et exécution du alter sans modification relance le bon fonctionnement.
Actuellement j'ai 2 possibilités:
* Mettre la procédure en mode "RECOMPILE" mais cela ne me plait pas trop
* Ne pas utiliser de procédure mais lancer le query complet directement depuis le client ce qui revient plus ou moins au recompile

Le problème que j'aimerais identifier, c'est l'origine de la corruption de SQL Server sur la procédure compilée mais je ne sais pas où chercher

[aieeeuuuuu]

Bonjour,

Quelle erreur obtenez vous quand vous la lancez depuis SSMS ?