Локальные временные таблицы (MSSQL) + ADO

← →
Рыжик (2002-12-15 14:02) [0]

Есть ADOQuery, который создаёт локальные временные таблицы:
CREATE TABLE [#TempTable] ([Field1] [bit] NOT NULL ).
Если я правильно понимаю, то когда пользователь отконнектится от сервера, эти таблицы должны удалиться автоматически.
Однако, повторяю следующие действия:
AdoConnection1.Connected:=true;
AdoQuery1.ExecSQL;//здесь создаются таблицы
...
AdoConnection1.Connected:=false;
Первые 2 раза всё работает, таблицы создаются. Но когда пытаюсь повторить те же действия в 3-ий раз, получаю ошибку:"There is already an object named "#TempTable" in database". И таблицы имеют вид, какими они остались после первого редактирования. При четвёртом вызове таблицы как после второго редактирования, и т.д.
Ничего не понимаю...

Причём через BDE всё работает как положено.

← →
passm (2002-12-15 14:39) [1]

Рыжик © (15.12.02 14:02)> Первое что приходит в голову - убедись, что происходит disconnect с BD. Посмотри список подключенных приложений средствами MSSQL (если возможно).

← →
Picco (2002-12-15 15:49) [2]

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

← →
Рыжик (2002-12-16 11:41) [3]

> Picco (15.12.02 15:49)

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

> passm © (15.12.02 14:39)

А disconnecta действительно не происходит. Но почему????????
AdoConnection1.Connected:=false; - работает без ошибок, в Delphi вроде всё ОК, а SQLServer по прежнему видит этот коннект.
Как тогда правильно отконнектиться?

← →
passm (2002-12-16 12:08) [4]

Рыжик © (16.12.02 11:41)> Не знаю :( . Я работаю через BDE.

← →
sniknik (2002-12-16 12:48) [5]

проверь чтобы AdoConnection1.Connected = false и в дельфи было IDE. т.е. стартовать программу с таким значением и в проге вначеле коннект подымать.

← →
Polevi (2002-12-16 12:55) [6]

# таблицы можно заменить постоянными, добавив в них поле SPID, в которое помещать @@SPID, кот идентифицирует тек сессию
Написать SP Login
CREATE PROCEDURE Login AS
DELETE FROM TempTable WHERE SPID=@@SPID

и вызывать ее сразу после коннекта

← →
Рыжик (2002-12-16 14:29) [7]

> sniknik © (16.12.02 12:48)

Так и есть.

> Polevi © (16.12.02 12:55)

Да, # таблицы можно заменить постоянными, но я хочу так ;)
Теперь уже просто интересно разобраться.

>All
Люди добрые, вы мне лучше скажите, это у всех так происходит, что после Connected:=false соединение продолжает жить на сервере, или только у меня?
Я проверяю процедурой sp_who. Если делаю Database1.Connected:=false (для BDE) - то коннект исчезает, если ADOConnection.Connected:=false (для ADO) - то остаётся пока программу не закроешь.
Может это какие-то особенности ADO, которых я не знаю? Раньше с ADO работать не приходилось, а тут шлёп - и сразу в лужу. И ни где ничего по этому поводу не могу найти...

← →
sniknik (2002-12-16 14:58) [8]

посмотрел, то же самое, если sp_who в query analizer-е смотреть. но
делаю
CREATE TABLE #TempTable (Field1 bit NOT NULL )
реконнект (ADOConnection.close, замена строки коннекта на ту же самую, ADOConnection.open)
и опять
CREATE TABLE #TempTable (Field1 bit NOT NULL )
ошибки нет, то есть удаляется
(если 2 раза подряд то "таблица уже есть")

← →
Рыжик (2002-12-16 15:32) [9]

> sniknik © (16.12.02 14:58)

А если так:
1.CREATE TABLE #TempTable (Field1 bit NOT NULL )
2.реконнект (ADOConnection.close, замена строки коннекта на ту же самую, ADOConnection.open)
3.и опять CREATE TABLE #TempTable (Field1 bit NOT NULL )
4.реконнект (ADOConnection.close, замена строки коннекта на ту же самую, ADOConnection.open)
5.и опять CREATE TABLE #TempTable (Field1 bit NOT NULL )

У меня на 3-м этапе тоже нет ошибки, а на 5-м есть, и если дальше повторять, то тоже ошибка.

← →
Владислав (2002-12-16 15:37) [10]

Глюк ADO.

← →
sniknik (2002-12-16 15:38) [11]

Нормально, 24 раза так сделал, дальше умаялся :о), но наверно и дальше тоже нормально.

← →
passm (2002-12-16 15:42) [12]

sniknik © (16.12.02 15:38)> Что считать за норму?

← →
sniknik (2002-12-16 15:45) [13]

Владислав © (16.12.02 15:37)
>Глюк ADO.

ну только если у нас версии разные, у меня MDAC 2.7 и 3 апгрейда для D6(может тоже различия).

проверял своей программой (точно ADO), хочеш скачай из кладовки (TestMdb), Reconect там делается по правой кнопке мыши на поле запроса пункт попап Reconect. (сделать одинаковые условия, если и через нее глюки... :-(((, то точно ADO)

← →
sniknik (2002-12-16 15:48) [14]

passm © (16.12.02 15:42)
гдето 150г, норма. :-))

в смысле? ошибок не дает значит нормально, и перетирает при реконнекте. или чтото другое имееш ввиду?

← →
passm (2002-12-16 15:50) [15]

sniknik © (16.12.02 15:48)> Ничего кроме выше перечисленного :))

← →
Владислав (2002-12-17 17:37) [16]

sniknik © (16.12.02 15:45)
Нет у меня там Popup никакого.

← →
sniknik (2002-12-17 18:14) [17]

А ты наверное Exe - вариант скачивал (он старее), скачай исходники под D6 скомпилится должен без проблем.
Или даже подожди я тебе вышлю (добавил еще изменение Font/charset для грида, можно игратся подбирать нужный).

(гдето минут через 20 от сего поста)

← →
Рыжик (2002-12-18 08:22) [18]

> sniknik © (16.12.02 15:45)

У меня и через TestMdb работает только 2 раза :((

← →
nikolo (2002-12-18 10:23) [19]

Hi всем! ИМХО тут дело просто напросто в самом серваке. Надо повникать каким образом он удаляет времсенные таблицы. Скорее всего он держит их у себя в какой-нибудь очереди. И когда вы пересоздаете таблицу 2,3 или 10 раз предыдущая таблица просто еще не была удалена серваком. Подтверждением моей "гипотезы" можно также считать то, что не у всех облом именно на 2 реконнекте, а по разному, т.е. у каждого разные сервера по быстродействию, по настройкам и т.д., а значит одни успечают быстро удалять временные таблицы, а вот другие притормаживают.
Может я и не прав, может и действительно ADO глючит...

← →
Рыжик (2002-12-18 10:59) [20]

Не, вряд ли это сервер. Через BDE-то работает прекрасно.
Что мне удалось выяснить: При дисконнекте соеденение в действительности не убивается. У меня при первом и втором коннекте создаются новые соеденение, а дальше при следующих коннектах поочерёдно используются первые два. Отсюда вся петрушка. Когда он берёт уже существующее соеденение, то для него уже есть такая таблица. Если бы происходил настоящий дисконнект, то всё удалялось бы.
То, что не у всех облом именно на 2 реконнекте, а по разному, подозреваю поисходит из-за того, что разное количество коннектов создаётся, а облом происходит в тот момент, когда начинает использовать существующий. Может у sniknik © вообще каждый раз создаётся новый коннект?...

← →
sniknik (2002-12-18 11:22) [21]

Рыжик © (18.12.02 08:22)
тогда давай версию проверять у меня (повторяюсь) MDAC 2.7
(и обновления для 6 дельфей все 3, может где в обертке глюк, патч который в "королевстве дельфи" не стоит (зачем если борланд сам исправил))

проверить версию
function ADOVersion:String; var con:TADOConnection; begin try con:=TADOConnection.Create(nil); Result:=con.Version; con.Free; except on E:Exception do Result:=E.Message; end; end;

Вызов ShowMessage("MDAC версия : "+ADOVersion); должен дать 2.7. Если нет качай обновление с микрософта mdac_typ.exe.

nikolo © (18.12.02 10:23)
попытался проверить твою теорию подключившись к самому медленному серверу у нас имеюшемся (даже не сервер рабочая станция PIII 850 256пам с установленыс MSSQL) тоже прошло без ошибок. Может конечно у кого сервер еще хуже? :-(((. Тогда их только пожалеть можно, а помоч нет.
to Рыжик проверь эту версию сделай таймаут какой между реконектом и повторным созданием таблици.

← →
sniknik (2002-12-18 11:24) [22]

Рыжик © (18.12.02 10:59)
> Может у sniknik © вообще каждый раз создаётся новый коннект?...

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

← →
Рыжик (2002-12-18 12:14) [23]

MDAC 2.5
Delphi Service Pack 2
Сейчас попробую поустанавливать чего-нибудь.

На счёт медленности сервера: точно сказать не могу, чего там стоит, нету доступа к нему в данный момент, но вроде никогда не жаловались. А насчёт таймаута - первоначально когда вознаикла ошибка, конекты вообще создавались отдельно друг от друга с очень большими перерывами.

← →
Рыжик (2002-12-18 12:39) [24]

> sniknik ©

Что за 3 обновление к Delphi6? У меня только 2. Где взять?

← →
sniknik (2002-12-18 13:00) [25]

взять к примеру отсюда
ftp://ftpd.borland.com/devsupport/delphi/d6/
но это не SP3 (неправильно выразился)
D6_RTL1_ent.exe
просто он ставится после upd2 ну и ...
т.е
D6_upd1_ent.exe //поставь тоже гдето читал что 2 его не полностью перекрывает (на всякий случай)
D6_upd2_ent.exe
D6_RTL1_ent.exe

← →
Рыжик (2002-12-18 13:23) [26]

Всё стоит, однако результат тот же

← →
sniknik (2002-12-18 14:07) [27]

Нда.., но должны же быть различия, может MSSQL у тебя 7-й (у меня 2000), может на сервере система к примеру NT, у меня (win2000server). Чтото мешает? прога какая.

у тебя есть возможность поставить MSSQL локально? (чтобы от сервера не зависеть). Или плюнуть на все и просто проверять таблицу перед созданием? если есть чистить.

← →
KSergey (2002-12-18 15:48) [28]

Ради интереса проверил - у меня все в точности, как у Рыжик. И соединение не хочет рваться (даже просто Connection подключаешь пустой - и все, пока прогу не закрыл, хотя вернее - компонент не уничтожил: если динамически его создавать, то после уничтожения соединение таки отваливается ;)
Кофигурация: D5 со всеми известными (мне) исправлениями от борланда, ADO 2.6, MS SQL 7 (хотя вроде тут он мало при чем должен быть.
А вообще, но это так, могу и сильно ошибаться, что-то вроде попадалось про то, что ADO цепляется за сервер а потом все равно не рвет коннект для скоросит чтоли... Хотя в описании самой объектов ADO вроде есть метод Close и к нему описание - для физического отцепляния от сервера... Правда в свете этого не понятно, как у других работает. (я не баловался со переназначением строки коннекта, т.к. это было не интересно - это тоже самое (по-моему) что и объект уничтожать - идейно, во всяком случае: обойти понятно как, это не интересно здесь.)
Попробую завтра: есть у меня проектик на VC++, который тоже через ADO работает, но там, понятно, не используется VCL ;).

← →
BlackTiger (2002-12-18 16:42) [29]

(D6+UPD1+UPD2+RTL_UPD1+MSSQL2000+MDAC2.7)

Действительно дельфийский косяк. Хе-хе, бормановцы блин...

После .Close; соединение не разрывается, а вот после .Destroy; - разрывается.

Ох уж это дельфийское ADO. На моей памяти уже второй неплохой косяк и одна слишком умная вещь.

← →
asmith (2002-12-18 16:43) [30]

Это все может быть проявлением такой штуки, как Connection Pooling (ODBC Connection Pooling, OLE DB Resource Pooling). Об этом написано в MSDN в статье "Pooling in the Microsoft Data Access Components". Цитата из нее:
If the connection is returned to the pool, the temporary table will persist until the connection is actually released—not just returned to the pool. If your application uses many temporary tables, this might create a resource problem on the server. If you use a stored procedure on the server to create the temporary table, the temporary table will be destroyed when the stored procedure goes out of scope. Temporary tables not created by stored procedures will be destroyed only after the connection is actually released from the pool.
В не также имеется рекомендация вырубать кеширование коннекций параметром OLE DB Services=-1 в сстроке соединения.

← →
Владислав (2002-12-18 17:31) [31]

> BlackTiger (18.12.02 16:42)

Это не борландовцы виноваты. Это поведение ADO.

> asmith (18.12.02 16:43)

А вот это уже интереснее. Только какой пул, если соединение одно?

← →
asmith (2002-12-18 17:53) [32]

А это неважно. Это такая особенность COM+ - вместо уничтожения объекта при отключении клиента делается его деактивация. Повторная активация объекта - намного более "легкая" операция, нежели его создание по новой. Логика такая - юзера отваливаются от источников данных, но мы (MS) подержим соединение еще немного, вдруг сейчас прийдет новый юзер.

← →
sniknik (2002-12-18 18:29) [33]

Для информации.
Клиентская машина точно ни при чем! Когда писал прошлое сообщение вспомнил что есть у нас сервер с подобными параметрами , NT SP4, MSSQL 7.0, пришлось идти "прописываться" :-), но результат интересный, именно на 3-м реконнекте к нему временная таблица не удалилась (описываемая ошибка). Тут же переключаюсь на другой сервер все работает (гонял до 10 раз) в общем из 6 машин с MSSQL только подключение к одной дает этот результат. Причем машина не из медленных, скорее наоборот PIII 1000*2, 1024мг. оперативки, SCASI RAID. Т.е. вряд ли не успевает.

настройки MSSQL? насчет COM asmith ты про рабочую станцию говориш или про сервер?

← →
asmith (2002-12-18 19:04) [34]

ИМНО наверное там, где находится OLE DB provider, хотя полной уверенности нет.

← →
sniknik (2002-12-18 19:37) [35]

чем дальше тем забавнее, пошол непосредственно на сервер (соединение с которым после 2 давало ошибку), коннект соответственно локальный сам на себя
делаю
CREATE TABLE #TempTable (Field1 bit NOT NULL )
реконнект
CREATE TABLE #TempTable (Field1 bit NOT NULL ) //таблица существует!

/т.е даже не 1 а ни разу не удаляется при рекконекте! только дестрой помогает.

не вы как хотите а я думаю MSSQL на этом сервере глючит. (либо наоборот правильно работает но я правил этих не знаю)

где бы еще 2000-й MSSQL на NT-ях найти, и 7.0 на 2000-ных? провести полные тесты так сказать.

← →
BlackTiger (2002-12-18 20:46) [36]

А попробуйте кто-нибудь импортировать в Дельфу саму type-library ADO и сделайте все через нее, в обход дельфийских надстроек.

Просто для проверки, конечно реально так работать на получится из-за несовместимости форматов рекордсетов (?).

А мне сейчас лениво и башка болит сильно.

← →
KSergey (2002-12-19 08:12) [37]

Небольшой "отчет", если позволите.

Для начала хотелось бы подчеркнуть одну штуку: как будет видно ниже, все крики "в борланде уроды" - как всегда оказались беспочвенными. (В подавляющем большенстве случаев это подтверждается так же и про MS и про прочее, но это так, к слову.)

Теперь о сути. Как и обещал, берем программу, не имеющую отношение ни к Delphi, ни к VCL ни к чему такому подобному. Короче работаем напрямую (ну более-менее ;) с ADO из MS VC++.

Что получаем: если объект ADO Connection не уничтожить после закрытия соединения - оно поддерживается (его видно при выполнении sp_who). Но примерно через минуту - закрывается!
Проверил теперь в Deiphi - тоже самое и происходит! Причем в первом случае использовался локальный сервер, во втором - на другой машине.

Теперь вспоминаем о посте asmith (18.12.02 16:43). Правда, применить указанный параметр в строке соединения не получилось. Возможно, не так писал. Но поиск в MSDN по OLE DB Services тут же привел к нужному описанию.
Оказывается, в ADO (OLE DB) примеряется Resource Pooling, который для ADO и OLE DB разрешен по умолчанию (правда вот так пойди с лету, да еще во вражеском языке догадайся, что это приведет к поддержке соединения после закрытия, ну да это так, про себя замечание). Более того, там же и про таймауты написано. Регулируются они, как и следовало ожидать, на клиенте. Так что сервера, платформы и быстродействие тут ни при чем. SPTimeout should be entered as a DWORD value under HKEY_CLASSES_ROOT\CLSID\{class id} where {class id} is the CLSID of the OLE DB provider. The default value is 60 seconds. Так вот она "примерно минута"!!!

Спасибо за внимание. Мне так же было интересно.

← →
Рыжик (2002-12-19 12:48) [38]

Ну и напоследок: чтобы отключить этот самый pooling надо в ConnectionString добавить "OLE DB Services = -2;" (а -1 как раз всё позволяет)

Всем спасибо за обсуждение. Отдельное спасибо asmith.

Локальные временные таблицы (MSSQL) + ADO Найти похожие ветки