T-SQL Query renvoie toujours les résultats dans SSMS, mais parfois ne renvoie pas les résultats lorsqu'il est exécuté via .NET via ADO.NET

Je suis plus qu'un peu confus avec un problème que j'ai rencontré 3 fois au cours des 2-3 derniers mois . Le titre de cette question décrit le problème, mais pour plus de détails:T-SQL Query renvoie toujours les résultats dans SSMS, mais parfois ne renvoie pas les résultats lorsqu'il est exécuté via .NET via ADO.NET

J'ai un SP qui retourne toujours les résultats sans problème lorsqu'il est exécuté par SQL Server Mgmt. Studio, cependant très rarement (mais assez pour causer des maux de tête importants) - il ne retournera simplement rien quand il est appelé via une application console.

J'ai vérifié les journaux d'erreurs/applications SQL Server et Windows Server que je connais (journaux SQL Server et tout dans l'Observateur d'événements sur le serveur Windows dans lequel réside SQL Server) et rien ne semble ...

Que diable pourrait être la cause de cela? L'application, SP, et tout fonctionne très bien. C'est juste que lorsqu'il est appelé à partir de l'application .NET, ce SP ne parvient pas à retourner des données. Je sais que la solution évidente serait de déboguer de VS et de voir les détails de la connexion (je n'obtiens aucune exception quand cela arrive) dans le débogueur du début à la fin de l'exécution du SP, mais ce n'est pas possible car le problème survient du bleu et n'est pas reproductible. Je veux l'empêcher de se reproduire.

Est-ce une connexion SQL spontanée possible ou quoi? Toutes les pensées, les commentaires et les suggestions sont grandement appréciés.

Source

2010-08-11 JackFrost

Il est possible que ce soit quelque chose avec le SP lui-même - l'afficher ici nous donnera quelque chose à examiner pour le déterminer. Le code C# peut aussi aider. – Russ

Comment savez-vous qu'il ne renvoie pas de résultats, plutôt que de renvoyer des résultats, mais la façon dont le C# les utilise est de ne pas traiter correctement les résultats (il les "perd"). –

ce n'est pas un délai d'attente? juste un resultset vide? – dotjoe

Un problème commun ici est les options SET en cours de lecture. Ce n'est pas évident, puisque vous les définissez rarement explicitement à partir de SSMS ou ADO.NET, mais ils peuvent être différents. En particulier, cela peut avoir un impact sur tout ce qui implique des colonnes indexées persistantes, sql xml, et une gamme d'autres comportements; null-égalité, concat-null, max-rows, schema-only (aucune donnée), interprétation des guillemets, arith-abort, etc.

Donc: trouvez quelles options SET sont en jeu.

Cela peut être un problème encore plus important si un code qui se comporte mal (dans la base de données ou le client appelant) définit une option dans un but quelconque et ne le rétablit pas. Surtout si ce code ne fonctionne que de temps en temps.

Source

2010-08-11 21:33:49

Je pense que par défaut, le seul différent est SET ARITH_ABORT, mais le comportement de celui-ci est maintenant le même si ANSI_WARNINGS est activé (les deux activent). –

Aussi - rien de dynamique - le SP fonctionne de la même manière à chaque fois qu'il s'exécute. Le seul thread commun que j'ai identifié est que cela se produit uniquement lorsque le serveur de base de données et la base de données sur laquelle le SP réside connaît un niveau d'activité élevé. Lorsque le serveur est presque inactif, ce problème ne se produit jamais. Une partie du problème est que l'application .NET utilise un ADO propriétaire.Un wrapper NET qui cache beaucoup d'informations SqlCommand que je dois inspecter. Je devrai attacher et déboguer cela. Merci pour toutes les réponses - ils m'ont fait penser à tous les angles de ce cas particulier de résultats d'OAD rarement disparaître. – JackFrost

Est-ce chose chose de dynamique du tout? Il se peut que vous créiez une instruction sql qui ne fonctionne pas dans certains cas. Le profilage est la seule chose à faire pour l'attraper en flagrant délit. Voir quelles valeurs il envoie quand il ne se comporte pas comme prévu.

Source

2010-08-11 21:38:14 HLGEM

Merci pour les commentaires. J'ai les options standard suivantes définies directement dans le SP: SET ANSI_NULLS SUR GO SET quoted_identifier GO J'ai couru profileur au cours d'une période où l'application .NET n'a pas pu obtenir les résultats et tout se termine s'exécute à la fin du SQL. C'est juste que l'application .NET semble "perdre" les résultats renvoyés. J'ai également débogué et déterminé que les résultats semblent simplement disparaître. – JackFrost

T-SQL Query renvoie toujours les résultats dans SSMS, mais parfois ne renvoie pas les résultats lorsqu'il est exécuté via .NET via ADO.NET

Répondre

Questions connexes