Моя первая реакция заключается в том, что это может быть проблема не вызова кросс-сервера, а одного вызова второго процесса из первого, и что этот может действовать по-разному в двух разных средах. ,
Мой первый вопрос: что произойдет, если вы удалите межсерверный аспект из уравнения? Если бы вы могли настроить тестовую систему, где ваш первый процесс вызывает ваш второй процесс, но второй процесс находится на том же сервере и / или в той же базе данных, у вас все еще возникает та же проблема?
В том же духе: по моему опыту, когда приложение и SSMS получали разные результаты, это часто было проблемой настроек хранимых процедур. Это может быть, как говорит Люк, NOCOUNT. Такое случалось с посторонними утверждениями PRINT в коде, хотя я, кажется, помню, что значение PRINT стало частью описания ошибки (очень нелогично).
Если что-нибудь возвращается в окне сообщений при запуске в SSMS, выясните, откуда оно поступает, и остановите его. Мне бы пришлось поискать технические термины, но я помню, что разные среды запросов имеют разную чувствительность к «ошибкам», и что соединение по умолчанию через SSSM не будет выдавать ошибку в определенные моменты времени, когда соединение ADO из языка сценариев будет .
Одна заключительная мысль: если это среда, попробуйте другие параметры в строке подключения вашей ASP-страницы. Например, если у вас есть соединение с OLEDB, попробуйте ODBC. Попробуйте родные и не родные драйверы SQL Server. Посмотрите, какие параметры строки подключения поддерживает ваш провайдер, и попробуйте любой из них, который, возможно, стоит попробовать.