Симонов Денисне проще ли это делать в кэширующие датасеты и завершать транзакцию?
Я как-то имел на эту тему разговор с Владом. И он сказал, что для девелоперов умолчательным был бы лучше автокоммит. Если уж транзакциями управлять не хотят (или не умеют), так пусть за них это делает сервер.
Собственно, не имею ничего против. Только вот исторически FreeIBComponents не делали fetchall при закрытии транзакции, а тупо убивали (а не обрубали) кэш. Зачем, почему - только Грегори Диц сможет ответить.
А после него - все копировали это поведение (точно так же как бездумно копировали умолчательный no_rec_version в драйверах).

С другой стороны, хорошо стартануть транзакцию, выполнить запрос, и потихоньку фетчить. Но если там N миллионов записей в перспективе, то FetchAll при Commit, ясное дело, вызовет разрыв шаблонов (мол, опять Firebird виноват). А если обрезать буфер по коммиту, то непонятно, что с ним делать если вдруг юзер решит ехать дальше, чем считано с сервера.

MS как-то пытается приучать, что либо FetchAll, либо никак (например, в dbExpress нет датасетов, зато есть абстрактный ClientDataSet). Но наследие прошлого висит на ноге тяжелой гирей.

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

Товарищ младший сержантсуществующее облако сведений о работе с FireBird провоцирует новичка начать работу не совсем правильно.
поясните, пожалуйста, ход неправильной мысли. Т.е. базовые сведения, и какие неправильные действия из них выводятся.
Насколько я в курсе, все неправильные выводы делаются либо на отсутствии базовых сведений, либо на их неверном понимании/прочтении.

Типа (все утверждения - либо сомнительные, либо неверные)
- надо делать backup/restore регулярно
- чтобы выключить сборку мусора, надо сделать gfix -housekeeping 0
- мусор попадает в бэкап
- версии возникают при чтении данных
- если мы стартуем читающую транзакцию (RW, которая ничего не пишет), то версии не накапливаются
и т.д.

У новичка, к сожалению, редко бывает задача разобраться, как это работает. Он думает что нечто работает "вот так", и пока ему по лбу не прилетит, он разбираться не начнет. Так что, не надо перекладывать с одной головы на другую.

p.s. еще один показательный пример - с "лишними" опциями бэкапа-рестора. Начинаешь спрашивать, нафига? - "так было до меня". Или - "я прочитал где-то, что надо так". Но где прочитал, и почему "надо так" - ответа нет.

Симонов ДенисТак речь уже не о ТС.
как раз о ТС. :-) он показал, что есть OAT. и сказал, что это "читающая транзакция, с которой не должно быть проблем".
Из чего выходит, что у него вовсе не RO RC.
После чего меня начали обвинять, что я провоцирую на "длинные читающие", убеждая людей использовать для этого только RO RC, чего они почему-то не делают, следуя только рекомендации "длинных читающих". И понеслась...
:-)

МимопроходящийЛЮБАЯ долгоиграющая транзакция - bad design.
не только в IB/FB - везде.
дык. Потому RO RC - это и есть "якобы транзакция". Сделали что могли на текущем движке.
Мимопроходящийтакая транзакция не даст консистентного чтения в реальных боевых условиях.
эээ. При чем тут снапшот? Ну даже если снапшот - раньше он один и был в InterBase, потом "враги" придумали RC.
Но длинные транзакции-то вылезли в компонентах.
Либо потеря кэша датасета после коммита, либо длинный TIBDatabase.DefaultTransaction, либо идиотское поведение компонент с автокомитом, которые тупо стартуют "дефолтную" транзакцию сразу после выполнения запроса и коммита. Нахрена они это делают НЕ перед выполнением запроса, я не знаю. В FIBPlus вообще умудрились для UpdateSQL/InsertSQL/DeleteSQL сделать длинную RW транзакцию с commitRetaining. Типа, апофеоз.

Вот потому и сделали RO RC, чтобы хоть как-то уменьшить вред от длинных транзакций. И для отчетов ее никто не предлагал.

Dimitry SibiryakovИз неё новичок выводит, что длинная RORC транзакция - это хороший, правильный способ взаимодействия с базой
тут согласен, я вообще собирался несколько статей с тематикой транзакций, версий и мусора переделать (местами). Сам читаю, и вижу, что кривовато написано.

Товарищ младший сержант?
ну здрасьте. По крайней мере было такое, по умолчанию. у pFIBDataSet две транзакции, чтения и записи. И на запись было по дефолту CommitRetaining. Я уж и не помню, что мне ответили, когда я спросил "а что это за ужас".

Товарищ младший сержантCommitRetainig для датасета (TpFIBDataSet) в FibPlus выполняется:
- когда включен режим автокоммита
ну и? это хорошо, что-ли?
Товарищ младший сержантСчитать такой режим "умолчанием" как бы не совсем справедливо, не?
в ФИБплюсе многие умолчания время от времени менялись. Например pFIBDatabase.SynchronizeTime по умолчанию True. Че, здорово, когда вдруг в приложении время с сервера устанавливается?

Товарищ младший сержантНу при чем тут теперь SynchronizeTime.
Ты практически не знаешь FIB+, но периодически наезжаешь.
при том, что это "неожиданное умолчательное поведение". А наезжаю я потому, что кроме этого есть и другие внезапно неожиданные поведения, умолчательные или нет.
Например, почему автокоммит должен завершаться по commitretaining, если уже фиг знает сколько времени как этот режим не рекомендуется?

p.s. FIBPlus я использую, но копаться в нем приходится только тогда, когда что-нибудь работает не так, как ожидалось. Или когда у компонент "слишком много ума". Меня не особо интересуют фишки FIBPlus, которые только запутывают или скрывают представление разработчика о том, как работает его программа.