У меня возник вопрос, можно ли сказать, что с позиции СУБД

FIBQuery.Transaction.CommitRetaining

это тоже самое, что

FIBQuery.Transaction.Commit;
FIBQuery.Open;

FIBQuery для СУБД вообще по барабану.
CommitRetaining и Commit, можно сказать, с некоторой оговоркой, одно и то же.

CommitRetaining - подтверждает сделанные изменения, но не закрывает НД - тоесть не нужно тянуть снова данные на клиент, а при Commit приходится переоткрывать НД, так что это не одно и тоже.

TObject, ну и расскажи чем так они сильно отличаются
Про то как это работает с клиента я уже говорил в соседней ветке и не стал повторяться

 - это не разница?

Взято с http://www.ibase.ru

И что это за побочные эффекты?

 http://www.ibase.ru

я лично вообще не использую CommitRetaining

Я так и ничего не понял, чем плоха CommitRetaining
Вот пользователь в нес изменения затем нажимаем кнопку сохранить по которой срабатывает CommitRetaining т.е. как я понимаю в БД произойдет Commit + на клиентскую часть пересылаются все обновления, тогда как простой Commit , вызовет на сервер коммит, но обновления (имеется ввиду обновления которые закоммитили другие пользователи за время, пока вносил изменения мой пользователь) на клиентскую часть не предут, и в что же, тогда плохого в CommitRetaining

Это сообщение отредактировал(а) Delphist - 13.3.2008, 17:54

 Не все обновления, а только те что сделаны этой таранзакцией, если другие пользователи будут редактировать эту же таблицу то изменений не будет видно пока не переоткрыть НД. Тогда как при простом Commit НД прийдется переоткрыть и будет видно все изменения которое были сделаны другими пользователями.

Что-т я так и не понял по твоим словам получается, что необходимо переоткрывать НД и при CommitRetaining'e и при Commit'e

При CommitRetaining Ваш НД остается открытым, но Вы не видите изменения сделанные другими пользователями. 

При Commit НД закроется сам (по крайней мере у меня так) и его прийдется открыть по новой. соответсвенно видим все изменения.

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

И все же чем же плох CommitRetaining по отношению к Commit'y

Нашел вот эту цитату:


Но из нее я так и ничего непонял и что значит CommitRetaining фактически препятствует сборке мусора, а простой коммит что не препятствует, и каком вообще мусоре идет речь?

Это сообщение отредактировал(а) Delphist - 14.3.2008, 09:57

"Мусор" - это старые версии записей (результат многоверсионности), а вообще-то вот статья, читайте: http://www.ibase.ru/devinfo/oitoat.htm и вообще там есть много чего по СУБД IB/FB

согласен. +

Статья на ibase.ru

не столько препятствует, сколько ...
для начала:
из этого имеем: если контекст транзакции не изменился, значит просто удерживаются версии записей(мусор) этой транзакции, сл-но только они и не попадут под сборку мусора. Мусор все равно соберется.

Какое-то противоречие

И еще если у меня транзакция в открыта режиме ReadCommited, то тогда получается что Commited и CommitedRetaining одно, а если в режиме snapshot, то тогда Commited и CommitedRetaining  не много разные вещи, правильно ли понял?

Я это тоже читал, но тут или какая-то неточность или я делаю чтото не правильно, у меня транзакция ReadCommitted с параметрами:

не видит изменения других транзакций, кроме своих, пока не переоткроется НД.

никакого противоречия нет.
Мусор появляется не только от одной транзакции.
Допустим стартанули 2 транзакции.
1. прочитала, потом добавила/обновила/удалила записи потом Commit.
2. прочитала, потом добавила/обновила/удалила записи потом CommitRetaining.
Так вот мусор от первой транзакции соберется, а от 2 нет.


давайте определимся, для кого мы проверяем видимость? Для клиента или сервера?
Так вот для клиента(при CommitRetaining) НД не закрывается и показывается весь текущий локальный кеш для записей.
Новые данные поступят только после переоткрытия, сл-но если нужны правильные(новые) данные, то делать CommitRetaining + DataSet.Open нет никакого смысла, лучше CommiT + DataSet.Open.
И это логично, т.е. CommitRetaining подтверждает другим транзакциям, что данные изменились.

To Deniz: В предидущем посте Вы действительно написали не совсем понятно, может думали иначе. 

А вот тут все понятно, я согласен.

Конечно же для клиента, сервер видит изминения в обеих случаях.

а какие изменения можно увидеть на клиенте, не переоткрыв НД? Это же как отчет, напечатал смотришь, второй раз напечатал, смотришь новые данные.

Я понимаю. Просто затупил на счет написаного в статье. Уже дошло. 

А почему от второй не убирается мусор, ведь же CommitRetaining как бы содерджит в себе Commit, т.е. данные одназначно закомичены и откатить их нельзя, зачем тогда сервер сохраняет мусор (промежуточные изменения)?

да, интересная тема.

это особенно интересно... 
и как бы его вычистить безболезненно))

Как уже было выше сказано транзакция которая подтерждена по CommitRetaining остается активной, а соответсвенно является "заинетесованной" в тех записях с которыми она работает, поэтому другие транзакции не могут чистить "мусор" пока она не завершится по Commit.


Ну во-первых в сборке "мусора" участвует каждая транзакция, в том числе и read-only.
Во-вторых backup БД делает уборку "мусора".
В-третьих параметр sweep interval задает значение при достижении которого произойдет sweep.

TObject, спасибо

делать COMMIT, а мусор сам соберется со временем, если только sweep interval > 0, если 0 мусор вообще собираться не будет

Что значит "заинетесованной", не совсем понятно?