во избежание одновременного запуска нескольких процедур / сценариев хранилища несколькими пользователями, возникает проблема с глобальной временной таблицей.

ема фона

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

С другой стороны, если вы хотите сгенерировать данные с динамической разметкой столбцов, вы обычно должны динамически создавать оператор SQL и выполнять его с помощью «exec sp_executesql». Поскольку компоновка данных неизвестна во время выполнения, вы не можете создать временную таблицу заранее, и однажды внутри оператора "exec sp_executesql" все временные таблицы, созданные там, привязываются к этой области и исчезают при возврате вызова, поэтому гораздо сложнее получить доступ к данным (т. е. ваши возможности более ограничены).

Моя конкретная ситуация

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

Таблица генерируется хранимой процедурой, которая динамически создает запрос, сохраняет его в переменной "@sql nvarchar (max)" и запускает ее, вызывая "exec sp_executesql @statement = @sql".

Оператор @sql был чем-то вроде «select * into #temptable from ...», но #temptable был уничтожен ко времени возврата «exec sp_executesql». Быстрое решение этой проблемы состояло в том, чтобы вместо этого просто использовать «## temptable» (то есть глобальную временную таблицу), потому что она сохраняется, когда хранимая процедура возвращает И я могу легко получить к ней доступ в вызывающей области (поскольку она имеет известное / статическое имя ).

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

Я не думаю, что возвращение табличных переменных (через выходные параметры) является опцией (также новой для SQL Server 2008), если это не может быть сделано без определения статического типа таблицы. Таблицы, которые генерирует моя хранимая процедура, являются динамическими и зависят от переданных входных параметров.

Встроенные табличные функции не подходят, потому что я запускаю циклы кода для построения запроса @sql и вызываю exec sp_executesql.

Табличные функции с несколькими операторами (вместо хранимой процедуры) также не подходят, поскольку такая функция должна иметь четко определенный формат таблицы, в то время как я запускаю dyanmic SQL, чтобы вернуть таблицу с переменным числом столбцы и имена столбцов в зависимости от значений входных параметров.

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

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

Ответы на вопрос(3)

Ваш ответ на вопрос