Не могу понять, в чем проблема.
Firebird поддерживает множественные транзакции.
Хочу в программе реализовать механизм: одна читающая транзакция, другая - пишущая.
Бывают случаи, когда когда нужно вручную управлять пишущими транзакциями, например, когда нужно сделать 100-200-1000 Update, потому что так быстрее - обновить 100 записей, а потом выполнить один раз commit.
Ну или если произошла ошибка на 95ой записи, то нужно отменить все изменения, сделав rollback.

Так вот.
Есть UniConnection с оной читающей TUniTransaction (read;nowait;rec_version;read_committed).
Есть UniSQL с одной пишущей TUniTransaction (write;nowait;rec_version;read_committed).
UniSQL выполняет в цикле обновление записей.




проблема в том, что я вызываю Rollback, но в базу изменения всё равно попадают, т.к. при q.Execute выполняется Commit без моего разрешения.

У UniConnection есть свойство AutoCommit. Если его включить то проявляется вышеуказанная проблема.

Далее делаем 2 изменения. Теперь отключаем AutoCommit у UniConnection и заменяем строку отказа изменений на


Но теперь изменения в базу не попадают, хотя я и вызываю Commit.

Получается, при (UniConnection1.AutoCommit := true) нельзя управлять транзакциями вручную, транзакции тупо подтверждаются после каждого Execute. А при (UniConnection1.AutoCommit := false) обновления в базу тупо не попадают, даже при явном вызове commit.

Зачем у TUniTransaction есть методы Commit и Rollback, если UniDAC на них тупо кладет болт, извините за выражение.
Ну или что я делаю не так?
Или на каждый TUniSQL, который хочет что-то записать в базу нужен свой отдельный TUniConnection?

В FibPlus было всё просто, понятно и прозрачно. В UniDAC чего-то странного намудрили.

** такс, разбираюсь, где напартачил...

добавил ещё



переписал блок



Вроде бы проблема ушла.
Т.е. если после цикла выполняю Rollback, то изменения в базу не попадают, значит, commit после каждой итерации (q.Execute) не выполняется.

P.S.
Сейчас у UniConnection свойство AutoCommit отключено. ЕМНИП, то это свойство имеет приоритет над AutoCommit`ами датасетов. Т.е. если AutoCommit у UniConnection включено, то UniDAC не будет обращать внимания на то, в каком состоянии свойство AutoCommit у датасетов. Таким образом, для ручного управления транзакциями в приложении свойство AutoCommit у UniConnection всегда должно быть отключено.

только в случае exception

Да, моя ошибка была в том, что я не знал, было ли исключение. Может быть оно действительно и было. А может и не было его.

Использую.
Но...
У меня было и так, что изменения в базу записывались, т.е. блок exception не выполнялся.
И при отладке блок exception не выполнялся.

Я уже решил. Т.к. у меня веб-приложение UniGUI, то приходится полностью выходить из процедуры и отменять все, выдав пользователю текст ошибки.
Модальное окно, чтобы спросить и подождать ответа, показать не получится.

Да будет флуд

Из-за того, что у меня UniConnection1.AutoCommit для ручного управления транзакциями пришлось установить в False, то оказалось, что теперь не работает AutoCommit у TUniQuery и не важно, включено это свойство или отключено.
Я к тому что, после того, как отредактировал данные прямо в сетке (DBGrid), нужно ручками подтверждать транзакцию после TUniQuery.Post.

По сравнению с FibPlus, у UniDAC немного непривычно, неудобно, можно даже сказать, что и неправильно, нелогично.
Если у набора данных TUniQuery (TUniSQL) включен режим AutoCommit, то он должен работать.
По идее, у TUniConnection вообще не должно быть свойства AutoCommit. Ну, или если оно есть, то должно работать только для метода TUniConnection.ExecSql(...).

Много простых таблиц-справочников типа id, name и их удобно редактировать прямо в таблице. Нет смысла пилить что-то дополнительное.
Я пока что выкрутился так: в событие OnAfterPost добавил строку