我们有一个经典的ASP应用程序，该应用程序可以正常工作，并且我们讨厌修改代码，以免引起一些已死的希腊神灵的愤怒。

最近，我们需要向应用程序中添加功能。功能实现实际上只是一个数据库操作，只需要对UI进行最少的更改即可。

我更改了UI并进行了较小的修改，以向sproc调用(sproc1)提交新的数据值。

在直接从ASP调用的sproc1中，我们向恰好位于另一台服务器sproc2上的另一个sproc添加了新的调用。

不知何故，这无法通过我们的ASP应用程序运行，但可以在SQL Management Studio中运行。

这是技术细节：

• 两台数据库服务器上的SQL 2005.
• Sql Login正在从ASP应用程序向SQL 2005 Server 1进行身份验证。
• 从服务器1到服务器2的链接服务器正在工作。
• 从SQL Management Studio执行sproc1时-工作正常。即使我们的代码使用相同的用户身份验证(应用程序sql登录)。
• 当独立于SQL Management Studio的sproc1进行调用时，sproc2可以工作。
• VBScript(ASP)捕获XML中发回给客户端的错误。错误号为0，错误描述为空白。从ADODB.Connection对象和任何Err.Number / Err.Description都从ASP方面在VBScript中生成。

因此，没有任何错误，也没有任何可重复性(即通过SQL Mgmt Studio)，有人知道这个问题吗？

我们当前的计划是分解并深入研究ASP方面的代码，并直接从ASP完全调用Server 2.sproc2，而不是尝试通过sproc1进行搭载。

解决方案

我们可能会遇到双跳问题

双跳问题是ASP / X页尝试使用位于与IIS服务器不同的服务器上的资源的情况。

Windows NT质询/响应不支持双跳模拟(因为一旦传递给IIS服务器，就无法将相同的凭据传递给后端服务器进行身份验证)。

我们应该使用SQL事件探查器验证尝试的第二个连接。

请注意，通过手动测试，我们不会通过IIS进行身份验证。仅当我们通过ASP / X页面启动sql时，此问题才显现出来。

更多资源：

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

示例代码可能会有所帮助：)我们是否要从存储过程中返回两个表？我不认为ADO 2.6可以处理返回的多个表。

我确实考虑过这一点(两次跳跃)，但是像我所指的那样，在sproc-in-s-sproc调用与通过INNER JOIN进行的典型跨服务器联接之间有什么区别？两者都将使用链接服务器凭据在Server1上执行，并向Server 2进行身份验证。

任何人都可以确认调用sproc跨服务器与对数据表进行联接不同吗？又为什么呢？

如果链接服务器配置是sql帐户，则该帐户被认为是两次跳转(因为我们所指的是NTLM两次跳转？)

关于是否有多个结果集返回否。 .net世界中的Server1.Sproc1和Server2.Sproc2都将是" ExecuteNonQuery()"，并且不返回任何内容(没有结果集，也没有返回值)。

尝试检查连接字符串中指定的用户对数据库的权限。
使用sql mgmt studio时，在连接字符串中使用相同的用户名登录数据库。

创建一些临时表来写入中间值和异常，因为它可以是调试应用程序的有效方法。

我们是否在两个存储过程中都设置了nocount？我曾经遇到过类似的问题，虽然我现在不记得确切的解决方法，但我知道这与它有关！

我可以检查一下：我们添加了sproc2吗？在此之前，它已经运行了好几年。

我们不能更改调用sproc2的位置吗？我们可以从ASP调用它，而不是从sproc1内部调用它？这样，我们就可以在代码中控制对SQL的身份验证，而不必依赖在服务器上设置任何信任或者共享远程身份验证。

链接服务器如何设置？通常，我们有一些关于如何向远程服务器进行身份验证的选项，包括以当前登录的用户身份登录或者指定要始终使用的SQL登录名。我们是否尝试过将其设置为始终使用特定帐户？那应该消除调用远程过程中的任何可能的权限问题。

我的第一个反应是，这可能不是调用跨服务器的问题，而是从第一个调用第二个proc的问题，并且这可能是在两种不同环境中的不同行为。

我的第一个问题是：如果从等式中删除跨服务器方面，会发生什么？如果我们可以建立一个测试系统，其中第一个proc调用第二个proc，但第二个proc在同一服务器和/或者同一数据库中，那么我们还会遇到相同的问题吗？

遵循相同的思路：根据我的经验，当应用程序和SSMS获得不同的结果时，通常这是存储过程设置的问题。正如卢克所说，可能是NOCOUNT。尽管我似乎记得PRINTed值已成为错误描述的一部分(这很违反直觉)，但我还是从代码中的多余PRINT语句中发生了这种事情。

如果我们在SSMS中运行此消息时，如果在"消息"窗口中返回任何内容，请找出其来源并使其停止。我将不得不查找技术术语，但我的回忆是，不同的查询环境对"错误"的敏感性不同，并且当通过脚本语言进行ADO连接时，通过SSSM进行的默认连接不会在某些时候引发错误。 。

最后一个想法：如果是环境因素，请尝试在ASP页的连接字符串上进行不同的设置。例如，如果我们有OLEDB连接，请尝试使用ODBC。尝试使用本机和非本机SQL Server驱动程序。检查提供程序支持哪些连接字符串选项，并尝试任何可能值得尝试的选项。

我有一个类似的问题，我通过设置nocount并删除打印命令来解决。