2009-04-12 3 views
2

Я два заявления EXEC TSQLTSQL сделать EXECUTE заявления синхронного

EXECUTE (N'MyDynamicallyGeneratedStoredProcedure') -- return 0 on success 
SELECT @errCode = @@ERROR ; 

IF (@errCode = 0) 
BEGIN 
    EXEC 'A Sql Statement using ##temptable created from first', @returnValue 
END 

Как сделать два EXEC-х синхронными? ; Сейчас второй EXEC не ждет завершения первого EXECUTE. Я попробовал выпустить WaitFor Delay, он ждет, но второй оператор EXEC никогда не возвращается обратно.

Спасибо.

Update, Вот больше информации:

  1. Сначала выполнить создает глобальную временную таблицу и заполнит его из сложного запроса на выборку.
  2. Второй EXEC - это хранимая процедура CLR, которая генерирует динамический SP на основе переменных из недавно созданной и заполненной глобальной таблицы Temp.

Теперь второй EXEC, жалуется, что таблица Global Temp не найдена.

Update 2, Найден вопрос (и меня !!)

ГБН (и других) был упор на ответ. EXEC IS синхронно. Проблема? Мое понимание самой проблемы .. я упомянул

  1. EXECUTE (N'MyDynamicallyGeneratedStoredProcedure ') - возвращение 0 в случае успешного завершения

Это должно было быть:

1 (а) ВЫПОЛНИТЬ (N'CreateMyDynamicStoredProcedure ') - возвращает 0 при успешном завершении

1 (б) EXECUTE (N'MyDynamicStoredProcedure') - возвращение 0 в случае успеха

Я пропустил, что 1 (b) был фактически выполнен где-то в другом месте и после шага (2).

(я должен пойти получить жизнь !!)

+0

Я подозреваю, что у вас есть другие проблемы. EXECUTE синхронно –

+0

Вы имеете в виду «Sequential»? Команды будут Sequential ... – MatBailie

+0

Согласитесь с Mitch. Не могли бы вы дать нам немного больше информации, пожалуйста? –

ответ

5

EXECUTE является sychronous. Второй работает после первого. Всегда.

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

1

Как указал gbn's answer, EXECUTE является синхронным.

Проблема может заключаться в том, что ваш объект SQL Connection в хранимой процедуре CRL находится не в том контексте, что и ваш пакетный скрипт. Ваша глобальная временная таблица должна была снята после запуска EXECUTE (N'MyDynamicallyGeneratedStoredProcedure')

Убедитесь, что вы создаете объект SQLConnection пропускания "context connection=true" Вот post answer, где кто-то имели подобную проблему с доступом к временной таблице, так как SQLConnection не был в том же контексте соединения.

Accessing TSQL created #temp tables from CLR stored procedure. Is it possible?

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

Обратитесь к этому сообщению о глобальном временном жизненном цикле (когда температура gloal отбрасывается)
Deleting Global Temporary Tables (##tempTable) in SQL Server

 Смежные вопросы

  • Нет связанных вопросов^_^