Проблема с вызовом хранимой процедуры из другой хранимой процедуры через классический ASP.

Question

У нас есть классическое ASP-приложение, которое просто работает, и нам не хотелось бы модифицировать код, чтобы не вызвать гнев давно умерших греческих богов.

Недавно у нас появилось требование добавить функцию в приложение.Реализация функции на самом деле представляет собой просто операцию с базой данных и требует минимальных изменений в пользовательском интерфейсе.

Я изменил пользовательский интерфейс и внес небольшие изменения, чтобы отправить новое значение данных в вызов sproc (sproc1).

В процедуре sproc1, которая вызывается непосредственно из ASP, мы добавили новый вызов к другой процедуре, которая расположена на другом сервере, sproc2.

Почему-то это не работает через наше приложение ASP, но работает в SQL Management Studio.

Вот технические подробности:

1. SQL 2005 на обоих серверах баз данных.
2. Вход в Sql проходит проверку подлинности из приложения ASP на SQL 2005 Server 1.
3. Связанный сервер с Сервера 1 на Сервер 2 работает.
4. При выполнении sproc1 из SQL Management Studio - работает нормально.Даже если он зарегистрирован как тот же пользователь, который использует наш код (вход в приложение sql).
5. sproc2 работает при вызове независимо от sproc1 из SQL Management Studio.
6. VBScript (ASP) фиксирует ошибку, которая передается в XML обратно клиенту.Номер ошибки — 0, описание ошибки пусто.Как из объекта ADODB.Connection, так и из того, что Err.Number/Err.Description выдает в VBScript со стороны ASP.

Таким образом, без каких-либо ошибок и какой-либо воспроизводимости (т.через SQL Mgmt Studio) – кто-нибудь знает проблему?

Наш текущий план состоит в том, чтобы разобрать и покопаться в коде на стороне ASP и сделать совершенно отдельный вызов Сервера 2.sproc2 непосредственно из ASP, а не пытаться использовать sproc1.

Answer 1

Моя первая реакция заключалась в том, что это может быть не проблема межсерверного вызова, а проблема вызова второго процесса из первого, и что этот может быть то, что действует по-разному в двух разных средах.

Мой первый вопрос таков:что произойдет, если убрать из уравнения межсерверный аспект?Если бы вы могли настроить тестовую систему, в которой ваш первый процесс вызывает второй процесс, но второй процесс находится на том же сервере и/или в той же базе данных, возникнет ли у вас та же проблема?

В том же духе:По моему опыту, когда приложение и SSMS получали такие разные результаты, это часто было проблемой настроек хранимых процедур.Это может быть, как говорит Люк, NOCOUNT.У меня случались подобные вещи из-за посторонних операторов PRINT в коде, хотя я, кажется, помню, что значение PRINTed становилось частью описания ошибки (очень нелогично).

Если что-либо возвращается в окне «Сообщения», когда вы запускаете это в SSMS, выясняете, откуда оно поступает, и останавливаете его.Мне пришлось бы поискать технические термины, но насколько я помню, разные среды запросов имеют разную чувствительность к «ошибкам», и что соединение по умолчанию через SSSM не будет выдавать ошибку в определенные моменты, когда соединение ADO из языка сценариев будет .

Одна последняя мысль:Если это проблема среды, попробуйте другие настройки в строке подключения вашей страницы ASP.Например, если у вас есть соединение OLEDB, попробуйте ODBC.Попробуйте собственные и неродные драйверы SQL Server.Узнайте, какие параметры строки подключения поддерживает ваш провайдер, и попробуйте любой из них, который, возможно, стоит попробовать.

Answer 2

У тебя есть установить nocount на установлено в обеих хранимых процедурах?Однажды у меня была похожая проблема, и хотя я сейчас не могу точно вспомнить, как я ее решил, я знаю, что это как-то связано с этим!

Answer 3

Вы можете страдать от проблема двойного прыжка

Проблема двойного перехода возникает, когда страница ASP/X пытается использовать ресурсы, расположенные на сервере, отличном от сервера IIS.

Вызов/ответ Windows NT не поддерживает олицетворение с двойным переходом (когда те же учетные данные после передачи на сервер IIS не могут быть переданы на внутренний сервер для аутентификации).

Вам следует проверить попытку второго подключения с помощью SQL Profiler.

Обратите внимание, что при ручном тестировании вы не проходите аутентификацию через IIS.Эта проблема проявляется только тогда, когда вы запускаете sql через страницу ASP/X.

Дополнительные ресурсы:

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

Answer 4

У меня была аналогичная проблема, и я решил ее, включив nocount и удалив команды печати.

Answer 5

Пример кода может помочь :) Вы пытаетесь вернуть две таблицы из хранимой процедуры;Я не думаю, что ADO 2.6 может обрабатывать возвращаемые несколько таблиц.

Answer 6

Я рассматривал это (двойной переход), но в чем разница между вызовом sproc-in-a-sproc, который я имею в виду, и вызовом sproc-in-a-sproc?типичное межсерверное соединение через INNER JOIN?Оба будут выполняться на Сервере 1 с использованием учетных данных связанного сервера и аутентификации на Сервере 2.

Может ли кто-нибудь подтвердить, что вызов кросс-серверной процедуры отличается от объединения таблиц данных?И почему?

Если конфигурация связанного сервера представляет собой учетную запись sql, считается ли это двойным переходом (поскольку вы имеете в виду двойной переход NTLM?)

С точки зрения того, возвращаются ли несколько наборов результатов — нет.И Server1.Sproc1, и Server2.Sproc2 будут «ExecuteNonQuery()» в мире .net и ничего не будут возвращать (без наборов результатов и без возвращаемых значений).

Answer 7

Попробуйте проверить права доступа к базе данных для пользователя, указанного в строке подключения.Используйте то же имя пользователя в строке подключения для входа в базу данных при использовании студии sql mgmt.

создайте временную таблицу для записи промежуточных значений и исключений, поскольку это может быть эффективным способом отладки вашего приложения.

Answer 8

Могу я просто проверить:Вы сделали добавление sproc2?До этого много лет работало нормально.

Не могли бы вы изменить место вызова spproc2?Можете ли вы вызвать его из ASP вместо того, чтобы вызывать его изнутри sproc1?Таким образом, вы контролируете аутентификацию SQL в коде и вам не нужно полагаться на настройку каких-либо доверительных отношений или общую удаленную аутентификацию на серверах.

Answer 9

Как настроен ваш связанный сервер?Обычно у вас есть несколько вариантов аутентификации на удаленном сервере, включая вход в систему в качестве текущего пользователя или указание имени входа SQL, которое будет всегда использоваться.Вы пробовали настроить его так, чтобы всегда использовать определенную учетную запись?Это должно устранить любые возможные проблемы с разрешениями при вызове удаленной процедуры...