Access и begin transaction

← →
Palladin © (2004-11-22 12:58) [0]

Гарантировано ли это будет обрабатыватся jet как транзакция?
q.sql.text:="begin transaction"; q.ExecSQL; q.SQL.text:="insert into tbl1 (d) values (null)"; q.ExecSQL; q.SQL.Text:="select @@Identity"; q.Open; Edit1.Text:=q.Fields[0].AsString; q.Close; q.SQL.Text:="commit"; q.ExecSQL;

что то гложут сомнения, а проверить: нет времени писать стрессовое приложение...

← →
Johnmen © (2004-11-22 13:25) [1]

Не знаю, как там с эмулированием тр-ий в джете для Аксеса, но то, что хочешь, делается так:
q.SQL.text:= "insert into tbl1 (d) values (null);"+ "select @@Identity"; q.Open; Edit1.Text:=q.Fields[0].AsString;

← →
sniknik © (2004-11-22 13:27) [2]

да, при условии подключения к одному конекту, только значение автоинкрементного счетчика увеличится даже при rollback transaction.
(т.е. при следующем инсерте будет пропуск на невнесенной записи)

и
q.SQL.Text:="commit transaction";

← →
sniknik © (2004-11-22 13:28) [3]

Johnmen © (22.11.04 13:25) [1]
а вот так в Access не пройдет. ;о(

← →
Palladin © (2004-11-22 13:30) [4]

Да будет вам известно аццесс не поддерживает скрипты.

← →
Palladin © (2004-11-22 13:34) [5]

[4] было Johnmen"у...

> [2] sniknik © (22.11.04 13:27)

Хм. Возможно ли такая ситуация, что при одновременном исполнении этой последовательности комманд через два разных соединения один @@Identity канет в лету, а второй вернется через оба соединения?

← →
Johnmen © (2004-11-22 13:54) [6]

> sniknik © (22.11.04 13:28) [3]
> а вот так в Access не пройдет. ;о(

Просто интересно, почему? Движок не поддерживает?

← →
msguns © (2004-11-22 14:24) [7]

>Palladin © (22.11.04 13:34) [5]
>Хм. Возможно ли такая ситуация, что при одновременном исполнении этой последовательности комманд через два разных соединения один @@Identity канет в лету, а второй вернется через оба соединения?

Кгхм.. Это как это ? Типа один заспрос через 2 соединения ?.
А если это будут 2 разных запроса, то какая разница
а) в одном коннекте они запущены или в разных - автоинкремент работает независимо.
б) как они (запросы) завершатся. "Серверу" ведь это по барабану.

← →
sniknik © (2004-11-22 14:57) [8]

> Просто интересно, почему? Движок не поддерживает?
ага, неподдерживает.

> Хм. Возможно ли такая ситуация, что при одновременном исполнении этой последовательности комманд через два разных соединения один
> @@Identity канет в лету, а второй вернется через оба соединения?
нет, скорее второй вызов инсерта во втором конекте вообще не сработает изза блокировки (если до комита/ролбека в первом вызов).
увеличение счетчика в любом случае как раз и гарантирует уникальность в любом случае. ;о) или полную отмену позиции.

> изза блокировки

Вот оно! :) это я и хотел узнать, сапасибо и респект.

> [7] msguns © (22.11.04 14:24)

Приложение многопоточное, есть пул из нескольких соединений и толпа потоков, каждый со своим TADOQuery.

>Palladin © (22.11.04 18:15) [9]

Сервер не "разбирает" потоков, для него есть просто запросы и транзакции (коннекты), в контексте которых они должны выполняться и завершаться (ролбак/коммит). Генераторы же работают вообще автономно, вне всяких контекстов. Поэтому если пришло n запросов на значение генератора, то он выдаст n разных значений, совершенно не разбираясь в каком соединении-транзакции-потоке эти запросы выполнялись.

Это понятно. Меня больше волновала ситуация когда:

Два соединения, два Query с двумя разными соединениями. Последовательность выполнения:

Первый Query. Insert
Второй Query. Insert
Первый Query. Select @@Identity

загвоздка была в том что вернет @@Identity, значение от "Первый Query. Insert" или "Второй Query. Insert"... утром встав на свежую голову я понял что никакого стрессового приложения писать не надо :) просто провести этот тест... я не знаком с внутренними механизмами работы джета, потому этот вопрос меня и волновал... все разрулилось так как мне и надо... "Первый Query. Select @@Identity" вернул "Первый Query. Insert"...

Access и begin transaction Найти похожие ветки