Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
[MS-SQL] Нет, так не работает. Говорит «Must specify table to select from». Запрос внутри... 13.02.03 14:03 Число просмотров: 1270
Автор: HandleX <Александр М.> Статус: The Elderman
|
CREATE TABLE #TempItemValues(
[ID] [int] NULL,
[PID] [int] NULL,
[ValueType] [int] NULL,
[ReadOnly] [bit] NULL,
[ValueName] [varchar](50) NULL,
[aValue] [sql_variant] NULL,
[PosID] [int] NULL)
Select * INTO #TempItemValues EXEC GetItemValues 1
SELECT * FROM #TempItemValues
GO
DROP TABLE #TempItemValues
GO
|
|
<programming>
|
[MS-SQL] Нифига не могу понять... Вопрос про получение данных из хранимой процедуры 13.02.03 12:28
Автор: HandleX <Александр М.> Статус: The Elderman
|
Из одной хранимой процедуры вызываем другую, которая возвращает набор данных, поскольку там есть выборка SELECT. Вопрос: как поместить эти данные во внешней процедуре, к примеру в курсор, или вставить их в другую таблицу, не модифицируя процедуру, в которой SELECT? Насколько я знаю, кроме EXEC ничего нет, а в EXEC нет ничего для этих целей. Типа EXEC INTO ;-))
Заранее всем спасибо.
|
|
[MS-SQL] Нифига не могу понять... Вопрос про получение данных из хранимой процедуры 13.02.03 13:32
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
|
А разве не работает конструкция
SELECT INTO Table1 EXEC <твоя внутренняя процедура>
?
ну, разумеется Table1 должна иметь структуру идентичную структуре набора, возвращаемого <твоя внутренняя процедура> .
|
| |
вот так будет правильно, только что проверил. insert into table_name exec proc_name. пример внутри 13.02.03 14:15
Автор: йцукенг <jcukeng> Статус: Member
|
use pubs -- Используем фирменную БД Майкрософта:), а фиг ли ж.
go
if object_id('test') is not null
drop proc test
go
create table #tmp (ID int NULL, textfield varchar(255))
go
create procedure test as
select top 20 Zip,au_lname from Authors
go
insert into #tmp exec test
go
-- убеждаемся, что все нормально
select * from #tmp
---
--------------
Замечу, что написанное запаришься переводить с MS SQL на другую СУБД - се ля ва.
PS. Шаман, а вот твой вариант не пашет. гы:)
|
| | |
Вай, как хорошо! Спасибо, буду юзать… Ты это сам додумался, или прочитал где? Вроде это нестандартная фича 13.02.03 15:45
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 13.02.03 15:50 Количество правок: 1
|
|
|
| | | |
справедливости ради замечу, что додумался до этого Б.Гейтс сотоварищи и любезно написал в хелпе к MS SQL Server 2000:) 13.02.03 16:02
Автор: йцукенг <jcukeng> Статус: Member
Отредактировано 13.02.03 16:04 Количество правок: 1
|
а пример написал я сам, гы:)
вот что меня удручает - увы, до сих пор нет в стандарте SQL такого типа данных, как выборка
пишешь, например,
declare @S dataset
потом делаешь
@s= select * from такая-то таблица, а потом юзаешь как хотишь.
увы, приходится делать селект во временную таблицу(btw:хорошо, хоть эта фича почти везде есть), что существенно загромождает тексты хранимых процедур:( да и работает не шустро
|
| | | | |
Ну дык есть же курсоры... Это как бы указатели на реальные записи. А если весь набор, то да, в temp… 13.02.03 16:09
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | | | | |
при программировании на TransactSQL курсоры должны быть аномалией, а не повседневностью. 13.02.03 16:28
Автор: йцукенг <jcukeng> Статус: Member
|
По идее, при программировании на TransactSQL курсоры должны быть аномалией, а не повседневностью.
во всех субд с которыми я сталкивался, при работе курсора наступают такие тормоза, что хоть стой, хоть падай.
и вообще, SQL задумывался как язык для работы с множествами.
но до сих пор в нем полноценной работы с ними нет:(
ведь классно было бы, если можно было написать
нечто такое:
declare @s recoredset
foreach @s=select нечто откуда-то DO exec proc_name @s
ведь именно отсутствие подобных конструкций и заставляет использовать курсоры.
|
| | | | | | |
Ну, тут тоже подводные камни... 13.02.03 17:23
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 13.02.03 17:31 Количество правок: 1
|
> declare @s recoredset
> foreach @s=select нечто откуда-то DO exec proc_name @s
> ведь именно отсутствие подобных конструкций и заставляет
> использовать курсоры.
Всё-таки у курсоров есть куча всяких параметров, в MS SQL они довольно быстрые, плюс динамические курсоры как-бы дают кое-какие преимущества (а вот они как-раз таки тормозные). Ведь по сути твоя конструкция, что ты хочешь, и есть курсор, а если же в переменную копировать сами данные (я не знаю что ты подразумеваешь под recordset), то накладные расходы будут ещё больше. Да и где их хранить? Опять же внутренне это будет реализовано как временная таблица, а сейчас у тебя как-бы «полный контроль над тем, как ты это имплементируешь» ;-)
Хотя и статические курсоры тоже внутренне реализованы как временные таблицы ;-)
|
| | | | | | | |
да нет тут подводных камней. 13.02.03 18:43
Автор: йцукенг <jcukeng> Статус: Member
|
> Всё-таки у курсоров есть куча всяких параметров, в MS SQL
> они довольно быстрые,
ага, быстрые.
пока нет транзакций:)
допустим, у тебя есть таблица "клиент" и в ней миллион записей.
ты хочешь в транзакции пробежаться по всем записям и для малой части из них (в зависимости от результата, возвращаемого некоторой хранимой пр-рой) вызвать какую-то другую хранимую процедуру.
если хоть один вызов второй процедуры завершился с ошибкой, нужно сделать откат транзакции.
а вот что происходит в действительности: такой курсор заблокирует нафиг всю таблицу и фактически все клиентские процессы, пытающиеся получить доступ к этой таблице, зависнут, пока не завершится транзакция [либо пока таймаут не произойдет):]. как правило, при использовании курсоров по таким большим таблицам происходит переполнение transaction log'а и вся база гикается со страшным свистом.
чтобы избежать или хотя бы уменьшить вероятность возникновения подобной ситуации, приходится делать выборку во временную таблицу ID-ов записей удовлетворяющих критерию отбора,
потом делать begin tran, открывать курсор, и бегать им по временной таблице, вызывая втоhую процедуру, закрывать курсор и далать commit.
это во-первых, некрасиво, во-вторых громоздко смотрится и сложнее отлаживается и, наконец, противоречит самой идее SQL - работы с рекордсетами вместо поочередной работы с отдельными кортежами.
как производители СУБД реализуют работу с множествами, меня заботит мало, гы:) у них конкуренция или как? так пусть же выживут на рынке только те, кто эту фичу реализует наиболее грамотно.
а то на дворе 21 век, а программирование на SQL от клиппера ушло всего на пол-шага:).
|
| | | | | | | | |
Читаем про опцию Optimistic при создании курсора... 14.02.03 05:33
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 14.02.03 05:34 Количество правок: 1
|
OPTIMISTIC
Specifies that positioned updates or deletes made through the cursor do not succeed if the row has been updated since it was read into the cursor. SQL Server does not lock rows as they are read into the cursor. It instead uses comparisons of timestamp column values, or a checksum value if the table has no timestamp column, to determine whether the row was modified after it was read into the cursor. If the row was modified, the attempted positioned update or delete fails. OPTIMISTIC cannot be specified if FAST_FORWARD is also specified.
|
| |
[MS-SQL] Нет, так не работает. Говорит «Must specify table to select from». Запрос внутри... 13.02.03 14:03
Автор: HandleX <Александр М.> Статус: The Elderman
|
CREATE TABLE #TempItemValues(
[ID] [int] NULL,
[PID] [int] NULL,
[ValueType] [int] NULL,
[ReadOnly] [bit] NULL,
[ValueName] [varchar](50) NULL,
[aValue] [sql_variant] NULL,
[PosID] [int] NULL)
Select * INTO #TempItemValues EXEC GetItemValues 1
SELECT * FROM #TempItemValues
GO
DROP TABLE #TempItemValues
GO
|
| | |
мдя, значит не работает... 13.02.03 14:09
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
