Надежность CommitRetaining

← →
Alex Y. (2002-01-15 18:38) [0]

В сети из 20 компов работает программа под FB6. Использую FIB+.
Сервер - NT4. Станции - разные винды. При работе с TFIBDataDetM
делаю trans1.CommitRetaining после post. Но периодически данные пропадают! Т.е. транзакция не отрабатывает. Сетка слабая, тормозная. Может нужен жесткий Commit? Но как продолжать работу с таблицами?

← →
Fareader © (2002-01-15 19:17) [1]

Тригеры не проверял?

← →
Alex Y. (2002-01-15 19:35) [2]

Тригеров нет
Вроде пишут, что надежнее вносить обновления через
TFIBDataSetM.Close;
TFIBDataSetM.Open;
Но как вернутся на текущую запись?

← →
Fareader © (2002-01-15 20:09) [3]

Ставь Bookmark
var book:Tbookmark;
begin
Book:=yar_query.GetBookmark;
yar_query.close;
yar_query.open;
yar_query.GotoBookmark(book);
yar_query.FreeBookmark(book);
end;

← →
Alexandr © (2002-01-16 06:58) [4]

изменения надо делать в отдельной транзакции и ей commit делать, а данные для отображения в отдельной транзакции- и ей commit вообще можно не делать если она read commited конечно

← →
olban © (2002-01-16 07:32) [5]

У меня CommitRetaining работает нормально, а подскажите, возможно ли при всех этих условиях использование вложенных транзакций, чтобы не запускать отдельную транзакцию, если данные обрабатываются в рамках одной транзакции, но и внутри возможны откаты каких-то данных?

← →
Alexandr © (2002-01-16 08:32) [6]

вложенных транзакций нет и не будет. Это изврат.
Это не надо, просто надо правильно проектировать.
действительно от commit/commitRetaining данные пропадать не должны. это точно.
Проблема в чем-то другом.

← →
olban © (2002-01-16 08:36) [7]

Как это изврат насчет вложенных транзакций, у меня такая ситуация возникала и не потому что неправильно спроектировал что-то, просто ситуация такая, и пришлось самому что-то делать с помощью дополнительных сохранений. Вот это действительно изврат!

← →
Alexandr © (2002-01-16 08:49) [8]

да уж...
как это "просто ситуация такая"?

← →
olban © (2002-01-16 09:43) [9]

Ну для чего применяется транзакция? Для того, чтобы мы могли свободно работать с данными не о чем не беспокоясь. В любой момент можно сделать откат. А если мы работаем в транзакции с этими данными, а для этих данных имеются еще данные, которые назовем под-данные, для которых мы тоже должны иметь возможность делать откат или сохранение. Использовать другую транзакцию невозможно, так как под-данные связаны с данными, а уровень Read Commit. Поэтому пришлось делать отдельное сохранение этих под-данных, далее сохранять изменения или делать откат, копировать сохраненные данные обратно.

2 Alexandr - если в одной транзакции делать изменения, а через другую показывать, то как при внесении изменений мне увидеть результат, если я для читающей транзакции не сделаю commit or rollback?

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

Тгда получается, что надо делать commit для обеих транзакций, а зачем тогда вторая?

← →
Alex Y. (2002-01-16 17:09) [13]

Кто нибудь в курсе, что реально происходит при commit и commitRetaining в FireBird (у меня версия летняя) ? Именно реально, а не по теории. Может, где упоминались баги на эту тему?
Могу сказать точно, что в сети первый диалект очень криво обрабатывает поля NUMERIC, и для поля NUMERIC(7б2) со значением 1.32 вполне может быть 1.31986746... Может и с транзакциями что-то криво?

Надежность CommitRetaining Найти похожие ветки