TSQL делает оператор EXECUTE синхронным - PullRequest
Новая
       8

TSQL делает оператор EXECUTE синхронным

2 голосов
/ 12 апреля 2009

У меня есть два оператора TSQL EXEC 

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, она ждет, но вторая инструкция EXEC никогда не возвращается назад.

Спасибо.

Обновление, здесь больше информации:

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

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

Обновление 2, обнаружена проблема (и это я !!)

GBN (и другие) были в упор на ответ. EXEC синхронно. Эта проблема? Мое понимание самой проблемы .. Я упомянул

  1. EXECUTE (N'MyDynamicallyGeneratedStoredProcedure ') - возвращает 0 в случае успеха

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

1 (a) EXECUTE (N'CreateMyDynamicStoredProcedure ') - возвращает 0 в случае успеха

1 (b) EXECUTE (N'MyDynamicStoredProcedure ') - вернуть 0 в случае успеха

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

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

Ответы [ 2 ]

5 голосов
/ 12 апреля 2009

EXECUTE является синхронным. Второй бежит после первого. Всегда.

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

1 голос
/ 12 апреля 2009

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

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

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

Доступ к созданным TSQL таблицам #temp из хранимой процедуры CLR. Возможно ли это?

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

См. Этот пост о глобальном временном жизненном цикле (когда глобальная температура снижается).
Удаление глобальных временных таблиц (## tempTable) в SQL Server

...