Вопрос: 2000й скул можно заставить запихнуть результат хранимой процедуры в табличную переменную?

MSSQL 2005, пишем к примеру

-- табличная переменная для инфы по первичным ключам
DECLARE @pk_info table ( TABLE_QUALIFIER varchar (100), TABLE_OWNER varchar (100), TABLE_NAME varchar (100), COLUMN_NAME varchar (100), KEY_SEQ varchar (100), PK_NAME varchar (100))    

-- получаем инфу по ключам таблицы
insert @pk_info exec sp_pkeys @tab_name;

все работает...

тот же скрипт на 2000м скуле дает

EXECUTE cannot be used as a source when inserting into a table variable.

Конечно можно воспользоваться временной таблицой, но просто не хотелось бы по ряду причин.
Особенно удручает тот факт, что фактически везде одно и то же: "Используйте табличные переменные где можете" =(

Аноним 972 пишет:

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

Какие причины ? ВОобще , временные таблицы и табличные переменные — это
одно и то же. Разница только в синтаксисе.

Здравствуйте, MasterZiv, Вы писали:

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

MZ>Какие причины ? ВОобще , временные таблицы и табличные переменные — это
MZ>одно и то же. Разница только в синтаксисе.

Как минимум еще время жизни.

Здравствуйте, Аноним, Вы писали:

А>Вопрос: 2000й скул можно заставить запихнуть результат хранимой процедуры в табличную переменную?

А>MSSQL 2005, пишем к примеру
А>

А>-- табличная переменная для инфы по первичным ключам
А>DECLARE @pk_info table ( TABLE_QUALIFIER varchar (100), TABLE_OWNER varchar (100), TABLE_NAME varchar (100), COLUMN_NAME varchar (100), KEY_SEQ varchar (100), PK_NAME varchar (100))    

А>-- получаем инфу по ключам таблицы
А>insert @pk_info exec sp_pkeys @tab_name;    
А>

А>все работает...

А>тот же скрипт на 2000м скуле дает

А>

А>EXECUTE cannot be used as a source when inserting into a table variable.
А>

А>Конечно можно воспользоваться временной таблицой, но просто не хотелось бы по ряду причин.
А>Особенно удручает тот факт, что фактически везде одно и то же: "Используйте табличные переменные где можете" =(

известная проблема mssql 2000, если в хранимке используется уже insert into, то ее нельзя использовать извне для такой же операции — с этим связана головная боль при работе с системными процедурами...я вышел из такой ситуации просто выдрав код sp_keys (sp_helptext или же просто через посмотрев в master) и написав свою процедуру, которая — ЕСЛИ нет временной таблицы с определенным именем, она ее создает и ложит туда результаты при помощи возвращаемого select-а и в конце сама делает select, если уже есть, очищает ее и также помещает результат, но в данном случае в конце select не делает.
Таким образом, если нам надо получить результат, создаем сначала временную таблицу определенной структуры (едиственный жирный минус такого подхода), запускаем хранимку, после выполнения результат у нас в temporary table, если же нужно просто посмотреть результат выполнения для административных целей, просто запускаем хранимку.

Здравствуйте, MasterZiv, Вы писали:

MZ>Аноним 972 пишет:

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

MZ>Какие причины ? ВОобще , временные таблицы и табличные переменные — это
MZ>одно и то же. Разница только в синтаксисе.

Попробовал вспомнить отличия, сходу припомнил несколько отличий:

1. Невозможность создать индексы на переменной, кроме первичного
2. Отсутствие поддержки статистик на табличных переменных
3. Соответственно, отсутствие рекомпиляций вызванных изменениями статистик
4. Джойны с табличными переменными — всегда loop joins, так как при отсутствии статистики оптимизатор подразумевает что данных там немного.
5. Отсутствие поддержки внешнего контекста транзакции (только statement based транзакции), соответственно разница в логировании в tempdb лог
6. Область видимости

Всем спасибо за развернуты ответ

Здравствуйте, andsm, Вы писали:

A>Попробовал вспомнить отличия, сходу припомнил несколько отличий:

A>1. Невозможность создать индексы на переменной, кроме первичного
A>2. Отсутствие поддержки статистик на табличных переменных
A>3. Соответственно, отсутствие рекомпиляций вызванных изменениями статистик
A>4. Джойны с табличными переменными — всегда loop joins, так как при отсутствии статистики оптимизатор подразумевает что данных там немного.
A>5. Отсутствие поддержки внешнего контекста транзакции (только statement based транзакции), соответственно разница в логировании в tempdb лог
A>6. Область видимости

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