Вопрос возник из-за отсутствия в TSQL конструкции Select from <StoredProc>

Есть запрос на выборку Select... на который нужно наложить дополнительное условие (Where, Join, In..) на соответствие некоторому набору значений поля (полей), определяемому хранимкой. Однако вставить в запрос на выборку непосредственно ХП нельзя. Если ХП сохранит результат во временной таблице #Table, то она "не видна" извне. Создавать на клиенте (в большинстве случаев запрос формируется на клиенте) временную таблицу и передавать ее имя в ХП не желательно по ряду причин.
Как выйти из тупика ?

"извне" - это откуда?
глобальные временные(##) не устраивают?

> Если ХП сохранит результат во временной таблице #Table,
> то она "не видна" извне.


Это не так.
1. В MSSQL есть два вида временных таблиц: #ttt и ##tttt
У первого время жизни равно (или меньше) времени жизни коннекта. Причём данная таблица "видна" только из данного процесса, из другого будет создан другой экземпляр.
Второй вид - более "глобальный", его время жизни - до перезагрузки сервера.
2. Все временные таблицы создаются в рамках tempdb
3. При создании временной таблицы внутри ХП она будет автоматически убита при выходе из ХП.
С другой стороны, тебе никто не мешает создать таблицу ручками, передать её в качестве параметра в хп, поработать с ней, сделать потом ещё какую-то выборку, и после этого ручками убить.

>Ega23 ©   (20.01.09 13:40) [2]
>> Если ХП сохранит результат во временной таблице #Table,
>> то она "не видна" извне.

>Это не так.

Как это "не так" сочетается с

>3. При создании временной таблицы внутри ХП она будет автоматически >убита при выходе из ХП.

?

Т.е. ничего кроме




не получится ?

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


Создай её до вызова ХП и бкдет тебе щщастье.


> Т.е. ничего кроме


Боюсь что да.
Если эстетически не нравится - ну оберни это дело другой хранимкой, или в этой же отдельную моду сделай. В TSQL с хранимками весьма большие вольности позволительны, в отличие от какого-нибудь FB или Postgres

>  из-за отсутствия в TSQL конструкции Select from <StoredProc>
Есть Select from <UserFunc>, - тоже не катит?

> b z   (21.01.09 10:47) [6]
+ Или вью организовать ... или то и то вместе :) вариант найти можно.

что обсуждается TSQL или MSSQL? в описании не указано хотя потом вроде ссылки/синтаксис MSSQL-я...

если второе то

> Т.е. ничего кроме
>
> Create Table #ttt...

> Exec .. (вызов ХП с передачей имени таблицы параметром или "вшивка" в ХП имени #ttt)

>  <ХП заполняет таблицу>

> Select ... left Join #ttt on ...

> не получится ?

можно заменить на
Create Table #ttt...
insert #ttt exec "процедура возвращающая рекордсет"
Select ... left Join #ttt on ...
drop Table #ttt...
и не надо ничего передавать внутрь процедуры.

>b z   (21.01.09 10:47) [6]
>Есть Select from <UserFunc>, - тоже не катит?

В теле функции нельзя взывать процедуры

>b z   (21.01.09 10:55) [7]
>+ Или вью организовать ... или то и то вместе :) вариант найти можно.

Дык в этом-то и вопрос заключается :)

>sniknik ©   (21.01.09 11:13) [8]
>что обсуждается TSQL или MSSQL? в описании не указано хотя потом вроде ссылки/синтаксис >MSSQL-я...
>если второе то

Да второе, конечно :)

>можно заменить на
> ...
>и не надо ничего передавать внутрь процедуры.

проблема в том, что та самая ХП достаточно навороченная (извлечение конструкторского состава изделия из графа констр.документации с кучей всяких нюансов: учет допустимых замен, расчет техотхода, определения маршрутов изготовления и т.д.) и не хотелось бы ее дублировать (именно ДУБЛИРОВАТЬ) аналогичной функцией.

шифр разузловываемого изделия, а также состав дополнительных (не относящихся к дереву состава) характеристик и условия выборки этих характеристик определяется на клиенте. Именно поэтому и возникла эта проблема. Т.к. кол-во клиентских приложений, юзающих дерево, весьма велико (и продолжает увеличиваться), хотелось бы придумать такой способ, который требовал бы минимальную ревизию проектов, вплоть до выноса текста самих запросов из IDE например на тот же сервер. В этом случае вообще проекты не надо было бы перекомпеллировать.
Но вот тут и вышла загвоздка.

Грубо говоря, есть некоторый select ... который возвращает то, что нужно задаче (приложению).
Этот селект приложение динамически дополняет условием Where исходя из текущих локальных требований пользователей. Все замечательно работает. Но работает ПО ВСЕЙ БАЗЕ. А надо чтоб только по изделию. Для чего и требуется "прикрутить" джоин к деталям и сборкам, относящимся к УКАЗАННОМУ изделию, а список этих самых деталей и сборок выдает та самая ХП.

Говоря иначе нельзя чтобы какие-то таблицы создавал сам клиент. Он должен просто выполнять запрос и все !

Ну уже вывернулся весь, объясняя суть - лучше не умею :)

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

> Говоря иначе нельзя чтобы какие-то таблицы создавал сам
> клиент. Он должен просто выполнять запрос и все !


Напиши ещё одну ХП, суть которой сводится к:

1. Create table #xxx
2. insert into #xxx exec твоя_навороченная_процедура
3. Select * from #xxx со всеми джоинами.

>Ega23 ©   (21.01.09 12:07) [12]

Не понял, каким боком в эту новую ХП я смогу встромить клиентский запрос с его (клиента) же списком where

иными словами вначале клиентского запроса задекларить две переменные int и varchar
выполнить процедуру, получить ее xml данные внутрь варчара.
далее exec sp_xml_preparedocument @id out,@xml;

далее выполнить клиентский запрос, а джойны евонные выполнять  к openxml(@id,'//......')

declare @id int;
declare @xml varchar(max);
set @xml = '<root><item id="1"/><item id="2"/></root>';
exec sp_xml_preparedocument @id out,@xml;
select * from clients
where cl_id in (select id from openxml(@id,'/root/item',0) with (id int))
exec sp_xml_removedocument @id;

здесь вся разница с реальным случаем в том, что вызов хранимки заменен на простое присвоение set @xml = ....

> Не понял, каким боком в эту новую ХП я смогу встромить клиентский
> запрос с его (клиента) же списком where


Через Exec. Динамический запрос, вобщем.

> В теле функции нельзя взывать процедуры
А у вас там еще есть вложенные процедуры?

> Для чего и требуется "прикрутить" джоин к деталям и сборкам,
>  относящимся к УКАЗАННОМУ изделию, а список этих самых деталей
> и сборок выдает та самая ХП.
хм, а зачем вам тут - "та самая ХП"? просто вставить необходимые условия "по месту" никак, т.е. все в одном?

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

недавно вот тоже делали автоматические расчеты на сервере, вышло около десятка процедур и несколько функций, тоже была засада в реализации элементов/алгоритмов комбинаторики ... решили с помощью clr (2005 сервер) + #temp таблицы, чуть-чуть подумали и все
а у вас пока выглядит как "дополняет условием Where исходя из текущих локальных требований пользователей", но делаете "странными" методами.
если таких параметров много и лень расписывать их всех, то дин. формирование запроса должно хватить, иначе и его наверное не надо
естественно, могу ошибаться

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

> Медвежонок Пятачок ©   (21.01.09 14:03) [18]
Так я и говорю, что может отказаться от ее использования в пользу позрачности, скорости и т.д.
Ну в общем трудно судить не видя реалии, может и она не такая навороченная, может ее переделать, а может уже что-то из предложенного хватит (например sniknik © [8], оно отвергнуто? почему?) ... да мало ли.