Некорректное поведение транзакций Firebird

[3Hub]

1. В обновленной версии 6.3.12 снова различается последовательность событий для пишущей транзакции при Edit и Append. Т.е. для Edit сначала происходит StartTransaction, а потом BeforePost.

2. При включении в UniQuery опции QueryRecCount во время Open стартуют обе транзакции: читающая и пишущая.

[ViktorV]

1. Последовательность событий при выполнении TUniQuery.Edit и TUniQuery.Append различается только в случае, когда свойство TUniQuery.Lock <> LmNone. Это корректное поведение для наших компонентов. При использовании отдельной пишущей транзакции и когда свойство TUniQuery.Lock <> LmNone, при вызове TUniQuery.Edit выполняется следующая последовательность событий:
- TUniTransaction.OnStart
- TUniQuery.BeforePost
- TUniTransaction.OnCommitRetaining
- TUniTransaction.OnCommit
- TUniQuery.AfterPost
2. Да, действительно, при включенной опции TUniQuery.Options.QueryRecCount стартуют обе транзакции и это тоже корректное поведение наших компонентов. При включенной опции TUniQuery.Options.QueryRecCount запрос на получение количества записей выполняется в контексте транзакции определенной в свойстве UpdateTransaction. Транзакция определенная в свойстве Transaction используется для открытия датасета (т.к. InterBase/Firebird требует активной транзакции для любой операции с данными).

[3Hub]

1. Подскажите, пожалуйста: чем отличается для Firebird режим lmOptimistic от LmNone?
К сожалению в документации к UniDac я этого не нашел.

2. Если для TUniQuery пишущая транзакция не указана, RecordCount все равно выполняется и оказывается, что совсем не обязательно задействовать пишущую. Но даже если это было бы настолько необходимо, то наверное корректно было бы каким-то образом ее сразу же завершать а не оставлять в активном состоянии.

[ViktorV]

1. Если свойство LockMode установлено в lmNone - блокировка записи не выполняется. При установке свойства LockMode в значение lmPessimistic запись, которую вы редактируете, будет заблокирована в момент вызова метода Edit. Если это свойство установлено в значение lmOptimistic, запись будет блокироваться непосредственно в момент вызова метода Post. Поэтому на сервере сохраняться изменения данных того пользователя, который последним вызвал метод Post, в независимости от того кто первый начал редактировать эти данные.
2. Это обычное поведение для наших компонентов. UpdateTransaction коммитится только в тот момент, когда нужно подтвердить изменение данных (например, при изменении или удалении записи в датасете). В остальных случаях UpdateTransaction будет завершена при закрытии соединения в зависимости от значения свойства DefaultCloseAction.