Читающая транзакция в dbExpress

← →
Juice © (2005-11-03 15:19) [0]

Очевидная задача. В TSQLConnection есть DirtyRead, ReadCommitted, RepeatableRead. В справке написано:
In addition, TSQLConnection lets you specify database-specific custom isolation levels. Custom isolation levels are defined by the dbExpress driver. See your driver documentation for details.
А где она, эта документация один Борланд наверное знает :) В нете ничего не находится, с справке тоже. Драйвер Interbase"овский, dbexpint.dll. Но остальные драйвера тоже интересуют, я на то и dbX юзаю, чтобы с разными серверами работать.

← →
Desdechado © (2005-11-03 15:58) [1]

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

← →
Juice © (2005-11-03 16:16) [2]

Может и нет связи. Тогда прошу обьяснить мне как dbExpress работает с транзакциями. Я понимаю так: если не создавать самому и не привязывать набры данных к собственной транзакции то библиотека стартует для кажого н.д. отдельную транзакцию, и завершает после вызова методов ApplyUpdates, CancelUpdates. По умолчанию вызывается CancelUpdates, т.е. если открыть а потом закрыть н.д. то данные на сервер не попадут. Как при таком раскладе задать "только чтение" ? Стартовать самому транзакцию, но как указать ей только читать ? Надо где-то указать ее параметры режима доступа, наверное ж в IsolationLevel, больше негде. Это все мои догадки.

← →
Курдль © (2005-11-03 16:27) [3]

Не уверен, но мне кажется, что такой изврат, как "читающая транзакция" есть только у IB. Но раз указано [D7, Все сразу], то это ставит в тупик.

Если открыть и закрыть НД (это DataSet.Open/.Close?) то данные на сервер, вроде, и не должны попасть...

Удивительно, что Вы ведь совершенно правильно описали про ApplyUpdates...

Чем не подходит метод "попадания данных на сервер" DataBase.ApplyUpdates([DataSet1, DataSet2...])?

← →
Desdechado © (2005-11-03 16:36) [4]

Уровень изоляции определяет, какие данные увидит клиент, если обратится к БД (подтвержденные, просто вписанные и неподтверженные и т.п.). Он не определяет, с какой целью клиент обращается к данным - только на чтение или нет.
Данные на сервер попадают только в случае вызовов специальным методов компонентов или при вызове пишущих запросов. И только при явном подтверждении оных.

← →
Juice © (2005-11-03 16:37) [5]

> Не уверен, но мне кажется, что такой изврат, как "читающая
> транзакция" есть только у IB. Но раз указано [D7, Все сразу],
> то это ставит в тупик.

Ну насчет других не знаю, но в мануалах Interbase как-то вычитал что read-only меньше нагружает IB-сервера последних версий. Ну да ладно с этим read, а если нужны остальные параметры ? Режим блокировки установить или отличный от стандартного уровень изоляции, например consistency, вариации с rec_version ?

← →
Desdechado © (2005-11-03 16:41) [6]

все это можно указать в параметрах SQLConnection

← →
Курдль © (2005-11-03 16:41) [7]

> Режим блокировки установить или отличный от стандартного
> уровень изоляции, например consistency, вариации с rec_version
> ?

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

← →
Juice © (2005-11-03 16:45) [8]

> Данные на сервер попадают только в случае вызовов специальным
> методов компонентов или при вызове пишущих запросов. И только
> при явном подтверждении оных.

А есть различия в работе с транзакциями между датасетами что получиили в результате выборки данные для редактирования и датасетами которые просто выполняют insert,delete или update ? В любом случае нужно вызывать ApplyUpdates. Кстати, интересно что будет если вызвать ApplyUpdates для датасета что находится в явной транзакции? Ща попробую. И если речь уже зашла об завершении, то как завершить CommitRetaining ? Или в других серверах такого нет ? Если нельзя то нехорошо получается, нет универсальности механизма.

← →
Курдль © (2005-11-03 16:48) [9]

> А есть различия в работе с транзакциями между датасетами
> что получиили в результате выборки данные для редактирования
> и датасетами которые просто выполняют insert,delete или
> update ?

Ну, по уму датасэты вообще не для активных DML (типа insert/update/delete).
Для этого больше подходят компоненты попроще. Или нормально отрабатывает связка DataSet - UpdateObject (последний-то и содержит эти DML и откликается на команды "Apply".

← →
Juice © (2005-11-03 16:50) [10]

> Если не хочешь нарваться на неприятность, "откудась не ждали"
> - юзай только ReadCommited. Если юзверей не много - блокировки
> не страшны. Только следи за "пишущими транзакциями", шоб
> не висели открытыми.

Весь топик организован чисто из любопытства, просто вопрос в голове промелькнул и понимаешь что не знаешь на него ответа. А ведь в будущем может и понадобиться и в весьма неудобный момент по закону подлости. Да и вообще шаманить с транзакциям чревато серьезными последствиями.

← →
Juice © (2005-11-03 16:57) [11]

> Ну, по уму датасэты вообще не для активных DML (типа insert/update/delete).
>
> Для этого больше подходят компоненты попроще. Или нормально
> отрабатывает связка DataSet - UpdateObject (последний-то
> и содержит эти DML и откликается на команды "Apply".

В старых добрых IBX все было просто и понятно, а тут и UpdateObject"a вовсе нету. Компоненты сами волшебным образом производят модификацию.

> Для этого больше подходят компоненты попроще.

Но все-таки, если допустим в TSQLDataSet выполнить DML-команду то когда она будет закомичена ? Когда я вызову ApplyUpdates. А если закрою датасет без вызова Apply то неявная транзакция завершится как Roollback ? Ведь так? Да и какие попроще, TSQLDataSet центральный компонент, остальные для перехода с BDE предназначены.

> Да и вообще шаманить с транзакциям чревато серьезными последствиями.

Да не сказал бы.
Просто рекомендую понапрасну их не дергать.
Без них не обойтись, когда модифицируется связанный пакет данных для разных таблиц и данные должны либо всем пакетом утвердиться в базе, либо "отмениться". В остальных случаях за глаза хватает "умолчательных".

Режим только-чтение вообще то нормально организуется раздачей только нужных грантов пользователям.

Поэкспериментировал я тут, и вот какая картина сложилась:
Эксп. 1 - неявные транзакции:
а) Как только выполнена DML команда SQLDataSet1.ExecSQL результат сразу появляется на сервере, т.е. мгновенный commit, чего и следовало ожидать. б) Если использовать CDS то данные попадают на сервер только после ClientDataSet1.ApplyUpdates, Close вызывает CancelUpdates, т.е. все как я и говорил.
Интересно то, что во время редактирования данных в CDS свойство SQLConnection1.InTransaction находится в false. Как же он тогда это делает, через какое подключение ?
Эксп. 2 - явные транзакции:
а) Все манипуляции delete/update/insert что выполняются во всех SQLDataSet"ах(настроенных на эту транзакцию) попадают в транзакцию и управляются ею - тут все ОК.
б) Стандартная цепочка - ClientDataSet1 - DataSetProvider1 - SQLDataSet1, SQLDataSet1.TransactionLevel установленн соотв. образом. Стартуем транзакцию, открываем CDS, при этом SQLDataSet открывается и сразу же закрывается, редактируем данные, выполняем Rollback - в гриде как были данные так и есть, CDS открыт! Короче, явные транзакции не затрагивают вообще CDS. Хоть это и не проблема вовсе ведь у него есть аналогичные методы Apply/Cancel но было бы интересно узнать как он выполняет модификации, через какое соединение и через какую транзакцию ? Мутно все как-то получается.

> Desdechado © (03.11.05 16:41) [6]
> все это можно указать в параметрах SQLConnection

А где взять эту самую информацию ? Можно-то можно, но надо же знать что там указывать!

Ха :) А вот что я нашел в ньюсгруппах:

Unfortunately there is no way to set the read only option for a
transaction with dbExpress. You can specify all transaction options
with the InterBase Express components.

Читающая транзакция в dbExpress Найти похожие ветки