LocalTable

← →
Bless (2003-06-18 09:05) [0]

Всем привет.

Работаю в Delphi с MS SQL Server 7.0

1)
ADOCommand1.commandText:="select * into #MyTable from Tab1
where Tab1.kod=1";
ADOCommand1.Execute;
- работает.

2)
ADOCommand1.commandText:="select * into #MyTable from Tab1
where Tab1.kod=:par1";
ADOCommand1.Parameters[0].Value:=1;
ADOCommand1.Execute;
- не работает. Точнее, никакой ошибки тут не выскакивает, но последующий
select * from #MyTable выдает ошибку "Нет такой таблицы #MyTable"

3)
ADOCommand1.commandText:="select * into ##MyTable from tab1 where tab1.kod=:par1";
ADOCommand1.Parameters[0].Value:=1;
ADOCommand1.Execute;
- работает!!!

Кто может мне объяснить причины вышеизложенного? Почему параметризированный запрос
не хочет создавать локальную временную таблицу (#MyTable) (2), но без проблем
создает глобальную временную таблицу (##MyTable) (3), в то время, как
непараметризированный запрос без проблем создает локальную (1)?

← →
MOA (2003-06-18 11:09) [1]

А Вы посмотрите SQL trace (так она, вроде называется в SQL 7), какие запросы поступают на сервер.
Могу ошибаться, не если таблица # не видна, то скорее всего, она была создана в отдельном батче, который создал ADO для выполнения Вашего запроса.
Удачи!

← →
sniknik (2003-06-18 11:27) [2]

а попробуй вот так второй запрос

ADOCommand1.commandText:= "select * into #MyTable from Tab1 where Tab1.kod=:par1 "+ "select * from #MyTable"; ADOCommand1.Parameters[0].Value:=1; ADODataSet1.Recordset:= ADOCommand1.Execute;

ADODataSet1 соответственно свяжи с гридом.
кстати надеюсь коннект у них обший?

← →
АлексейК (2003-06-18 12:44) [3]

Все верно.
#MyTable таблица временая, время жизни - только в текущей сессии.

← →
Bless (2003-06-19 09:44) [4]

snilkin> Cпасибо, работает!!! (Правда не ADOCommand взял а ADOQuery, а то в строке
ADODataSet1.Recordset:= ADOCommand1.Execute;
на Recordset ругается, но это мелочи)
Если еще и объяснишь почему, цены тебе не будет. :)

MOA> Спасибо за совет, посмотрю. Заодно узнаю, что такое батч :)

АлексейК> Да она мне только в текущей сессии и нужна.
Но если в запросе есть параметры и таблица с одной решеткой, то ее нет даже в текущей сессии. А если параметров в запросе нет или таблица с двумя решетками, то никаких проблем. ПОЧЕМУ.
Может я неправильно понимаю, что такой текущая сессия?
Подключаюсь через ТADOConnection, на этом ADOConnection висит ADOCommand и ADOQuery. В ADOCommand делаю select into #MyTable..., в ADOQuery select * from #MyTable. Они ведь в одной сессии, или я не понимаю чего-то?
А если они не в одной сессии, то почему все работает когда нет параметров?

← →
sniknik (2003-06-19 11:31) [5]

Bless (19.06.03 09:44)
> на Recordset ругается, но это мелочи)
сорри, в этом случае код должен быть немного сложнее (2 команды в пакете - 2 рекордсета) не подумал сразу, вот так будет работать.
var Recordset: _Recordset; OleVar: OleVariant; begin ADOCommand1.commandText:= "select * into #MyTable from Tab1 where Tab1.kod=:par1 "+ "select * from #MyTable"; ADOCommand1.Parameters[0].Value:=1; Recordset:= ADOCommand1.Execute; Recordset:= Recordset.NextRecordset(OleVar); ADODataSet1.Recordset:= Recordset;
(первый просто пустой)

> Если еще и объяснишь почему, цены тебе не будет. :)
открой профайлер да посмотри, что выполняется в случае с параметром и без
пример запросов (базу взял Northwind для примера)
первый с параметром
ADOCommand1.commandText:= "select * into #MyTable from Territories where RegionID=:par1"; ADOCommand1.Parameters[0].Value:=1; ADOCommand1.Execute; ADODataSet1.CommandText:= "select * from #MyTable"; ADODataSet1.Open;
что посылается реально (и от чьего имени)
SQL:BatchCompleted SET FMTONLY ON select RegionID from Territories SET FMTONLY OFF SQL:BatchCompleted SET NO_BROWSETABLE ON RPC:Completed declare @P1 int set @P1=1 exec sp_prepare @P1 output, N"@P1 int", N"select * into #MyTable from Territories where RegionID=@P1", 1 select @P1 RPC:Completed exec sp_unprepare 1 SQL:BatchCompleted SET NO_BROWSETABLE OFF RPC:Completed exec sp_executesql N"select * into #MyTable from Territories where RegionID=@P1", N"@P1 int", 1 SQL:BatchCompleted SET NO_BROWSETABLE ON SQL:BatchCompleted select * from #MyTable

теперь без параметра
ADOCommand1.commandText:= "select * into #MyTable from Territories where RegionID=1"; ADOCommand1.Execute; ADODataSet1.CommandText:= "select * from #MyTable"; ADODataSet1.Open;
реально
SQL:BatchCompleted SET NO_BROWSETABLE ON RPC:Completed declare @P1 int set @P1=1 exec sp_prepare @P1 output, NULL, N"select * into #MyTable from Territories where RegionID=1", 1 select @P1 RPC:Completed exec sp_unprepare 1 SQL:BatchCompleted SET NO_BROWSETABLE OFF SQL:BatchCompleted select * into #MyTable from Territories where RegionID=1 SQL:BatchCompleted SET NO_BROWSETABLE ON SQL:BatchCompleted select * from #MyTable

по моему все очевидно вызов во втором случае идет в одном контексте в первом прерывается (на первые строчки не обращай внимания это подключение, важны последнии 2)

← →
sniknik (2003-06-19 11:34) [6]

еще раз сорри.
> важны последнии 2), не 2 а 4 (ну если SET NO_BROWSETABLE OFF выкинуть то 2 :о))

← →
MOA (2003-06-19 11:56) [7]

Вот цитата из Books online (BOL):

Temporary tables are automatically dropped when they GO OUT OF SCORE, unless explicitly dropped using DROP TABLE:
A local temporary table created in a stored procedure is dropped automatically WHEN THE STORED PROCEDURE COMPLETES. The table can be referenced by any nested stored procedures executed by the stored procedure that created the table. The table cannot be referenced by the process which called the stored procedure that created the table.
All other local temporary tables are dropped automatically at the end of the current session.

Т.е время жизни временной таблицы - именно область видимости.
А может, временная таблица не очень-то и нужна? MS SQL довольно эффективно кэширует запросы и планы выполнения. М.б., стоит использовать хранимые процедуры или функции?
Удачи!

← →
Bless (2003-06-19 16:07) [8]

Всем большое спасибо!

А что касается нужна-не нужна... Надо как-то сохранить промежуточный запрос, из которого потом будет делаться выборка в других запросах.
Представления не подходят, ибо в запросе есть группировка. Локальные таблицы - первое и единственное, что пришло в голову. Но поскольку я новичок, то вполне допускаю существование лучших вариантов. Если есть что сказать по этому поводу- с удовольствием выслушаю.

← →
MOA (2003-06-19 16:45) [9]

>Надо как-то сохранить промежуточный запрос, из которого потом будет делаться выборка в других запросах.
А может, использовать этот запрос как подзапрос в нужных местах, если он не очень долго выполняется? Будут не нужны временные таблицы, и данные будут "живее". Сервер довольно эффективно кэширует, в том числе и планы выполнения, так что часть плана, относящегося к этому подзапросу (если он часто происходит) будет всегда в кэше. Ни, и часть данных тоже.
Удачи!

← →
Bless (2003-06-25 17:55) [10]

← →
SergSuper (2003-06-25 18:22) [11]

Временные таблицы - это хорошо!
Просто надо их создавать через CREATE TABLE...

← →
Bless (2003-06-26 09:31) [12]

SergSuper (25.06.03 18:22)> Да мне просто лень было. Там столбцов 25 где-то

LocalTable Найти похожие ветки