Problème lors de l'appel d'une procédure stockée à partir d'une autre procédure stockée via ASP classique

Question

Nous avons une application ASP classique qui fonctionne simplement et nous n'aimons pas modifier le code sous peine d'invoquer la colère de dieux grecs disparus.

Nous avons récemment eu l'obligation d'ajouter une fonctionnalité à une application. L’implémentation des fonctionnalités n’est en réalité qu’une opération de base de données nécessitant une modification minimale de l’interface utilisateur.

J'ai modifié l'interface utilisateur et apporté la modification mineure pour soumettre une nouvelle valeur de données à l'appel de sproc (sproc1).

Dans le sproc1 appelé directement à partir d'ASP, nous avons ajouté un nouvel appel à un autre sproc situé sur un autre serveur, sproc2.

D'une certaine manière, cela ne fonctionne pas via notre application ASP, mais dans SQL Management Studio.

Voici les détails techniques:

1. SQL 2005 sur les deux serveurs de base de données.
2. Sql Login s'authentifie depuis l'application ASP vers SQL 2005 Server 1.
3. Le serveur lié du serveur 1 au serveur 2 fonctionne.
4. Lors de l'exécution de sproc1 à partir de SQL Management Studio - fonctionne correctement. Même utilisé avec le même utilisateur que notre code (l’identifiant SQL de l’application).
5. sproc2 fonctionne lorsqu'il est appelé indépendamment de sproc1 à partir de SQL Management Studio.
6. VBScript (ASP) capture une erreur qui est renvoyée dans le fichier XML au client. Le numéro d'erreur est 0, la description de l'erreur est vide. À la fois à partir de l'objet ADODB.Connection et de n'importe quel type Err.Number / Err.Description en VBScript à partir du côté ASP.

Donc, sans aucune erreur, ni reproductibilité (c.-à-d. via SQL Mgmt Studio) - est-ce que quelqu'un connaît le problème?

Notre plan actuel est de décomposer et de creuser dans le code côté ASP et de faire un appel complètement séparé au serveur 2.sproc2 directement à partir d'ASP plutôt que d'essayer de se greffer sur sproc1.

Answer 1

Ma première réaction est qu’il ne s’agit peut-être pas d’appeler plusieurs serveurs, mais bien d’appeler un deuxième processus à partir d’un premier, et que ceci pourrait bien être ce qui se passe différemment entre les deux environnements.

Ma première question est la suivante: qu’arrivera-t-il si vous supprimez l’aspect inter-serveur de l’équation? Si vous pouviez configurer un système de test où votre premier proc appelle votre deuxième proc, mais que le deuxième proc est sur le même serveur et / ou dans la même base de données, avez-vous toujours le même problème?

Dans le même ordre d'idées: d'après mon expérience, lorsque l'application et SSMS ont obtenu des résultats différents, il a souvent été question des paramètres des procédures stockées. Comme le dit Luke, cela pourrait être NOCOUNT. Ce genre de chose s'est produite à partir d'énoncés PRINT superflus dans le code, même s'il me semble me rappeler que la valeur PRINTed est devenue une partie de la description de l'erreur (très contre-intuitivement).

Si quelque chose est renvoyé dans la fenêtre Messages lorsque vous l'exécutez dans SSMS, recherchez son origine et arrêtez-le. Je devrais rechercher les termes techniques, mais je me souviens que différents environnements d'interrogation ont des sensibilités différentes aux "erreurs", et qu'une connexion par défaut via SSSM ne génère pas d'erreur à certains moments lorsqu'une connexion ADO à partir d'un langage de script sera.

Une dernière pensée: s'il s'agit d'un problème d'environnement, essayez différents paramètres sur la chaîne de connexion de votre page ASP. Par exemple, si vous avez une connexion OLEDB, essayez ODBC. Essayez les pilotes SQL Server natifs et non natifs. Vérifiez les options de chaîne de connexion prises en charge par votre fournisseur et essayez-en d’autres qui en valent la peine.

Answer 2

Avez-vous activé nocount dans les deux procédures stockées? J'ai eu un problème similaire une fois et, même si je ne me souviens pas exactement comment je l'ai résolu pour le moment, je sais que cela y était pour quelque chose!

Answer 3

Vous pourriez souffrir de la problème de double saut

Le problème de double saut survient lorsque la page ASP / X tente d'utiliser des ressources situées sur un serveur différent du serveur IIS.

Challenge / Réponse Windows NT ne prend pas en charge l'emprunt d'identité à double saut (une fois passé serveur IIS, les mêmes informations d'identification ne peuvent pas être transmises à un serveur principal pour l'authentification).

Vous devez vérifier la tentative de deuxième connexion à l'aide de SQL Profiler.

Notez qu'avec vos tests manuels, vous ne vous authentifiez pas via IIS. Ce problème ne se manifeste que lorsque vous démarrez SQL via la page ASP / X.

Plus de ressources:

• http://support.microsoft.com/kb/910449
• http://support.microsoft.com/kb/891031
• http://support.microsoft.com/kb/810572

Answer 4

J'ai eu un problème similaire et je l'ai résolu en activant nocount et en supprimant les commandes d'impression.

Answer 5

Un exemple de code pourrait aider :) Essayez-vous de renvoyer deux tables à partir de la procédure stockée; Je ne pense pas qu'ADO 2.6 puisse gérer le retour de plusieurs tables.

Answer 6

J'ai bien envisagé cela (double saut), mais quelle est la différence entre un appel sproc-in-a-sproc auquel je fais référence et une jointure multiserveur typique via INNER JOIN? Les deux seront exécutés sur Serveur1, à l'aide des informations d'identification du serveur lié et de l'authentification sur le serveur 2.

Quelqu'un peut-il confirmer qu'appeler un serveur inter-serveurs sproc est différent de la jointure sur des tables de données? Et pourquoi?

Si la configuration du serveur lié est un compte SQL, est-ce considéré comme un double saut (puisque vous parlez de double sauts NTLM?)

En ce qui concerne le retour de plusieurs ensembles de résultats - non. Server1.Sproc1 et Server2.Sproc2 seraient tous deux "ExecuteNonQuery ()". dans le monde .net et ne renvoie rien (pas de résultats ni de valeurs de retour).

Answer 7

Essayez de vérifier les autorisations accordées à la base de données pour l'utilisateur spécifié dans la chaîne de connexion. Utilisez le même nom d'utilisateur dans la chaîne de connexion pour vous connecter à la base de données à l'aide de SQL mgmt studio.

créez une table temporaire pour écrire les valeurs intermédiaires et les exceptions, car cela peut être un moyen efficace de déboguer votre application.

Answer 8

Puis-je simplement vérifier: vous avez ajouté Sproc2? Avant cela, cela fonctionnait bien depuis des lustres.

Ne pourriez-vous pas changer d'où vous appelez sproc2? Plutôt que de l'appeler de l'intérieur de sproc1, pouvez-vous l'appeler de l'ASP? De cette manière, vous contrôlez l'authentification SQL dans le code et vous n'avez pas à compter sur la configuration d'approbations ni d'authentification à distance partagée sur les serveurs.

Answer 9

Comment votre serveur lié est-il configuré? Vous avez généralement quelques options pour l'authentification sur le serveur distant, notamment la connexion en tant qu'utilisateur actuellement connecté ou la spécification d'une connexion SQL à utiliser systématiquement. Avez-vous essayé de le configurer pour qu'il utilise toujours un compte spécifique? Cela devrait éliminer tout problème d’autorisations lors de l’appel de la procédure distante ...