_Vasilisk_Получается, что смысла убирать флаг nowait нет никакого? Он актуален только при Rollback?
грубо говоря, wait может иметь смысл при snapshot (concurrency) или table reserving (consistency). Для read committed wait только вреден. Вообще wait плох тем, что он приводит к повисанию приложения.
Потому и ввели в 2.0 параметр транзакции [LOCK TIMEOUT seconds].

_Vasilisk_1) Транзакции read_commited, rec_version
ну слава богу!

_Vasilisk_И все таки смысла isc_update_conflict я не понял. "Чтобы не приходилось в саппорте отвечать на вопросы" - как-то неубедительно звучит
есть две модели обработки такого конфликта

Допустим, есть А, делает update, и есть Б, делает update в wait.

1. при commit транзакции А транзакция Б обломится, т.е. получит ошибку lock conflict ибо конкурирующая транзакция ИЗМЕНИЛА данные, а на какие, хрен его знает, поэтому транзации Б запрещается их перезаписывать. Так работает InterBase и Firebird

2. при commit транзакции А транзакция Б перепишет сделанные ею изменения, и не получит ошибки о конкурирующем update. Так, вроде бы, сделано в Оракле.

На клиентской стороне у ДатаСетов бывают аналогии этому поведению. Не в смысле конкурентного обновления, а в смысле убивания изменений, сделанных предыдущей транзакцией. То есть, перед входом в режим редактирования запоминаются столбцы строки, а при отправке update формируется запрос, который не проверяет ничего, проверяет изменения, или проверяет все.
upWhereKeyOnly - проверяется только ID записи, на остальное кладется болт
upWhereChanged - проверяются столбцы, которые менялись, плюс ID. Если старые значения уже не те, что были считаны перед переходом в режим редактирования, выдается ошибка.
upWhereAll - тут контролируются все столбцы, независимо, менялись они при редактировании, или нет. Главное, чтобы все столбцы имели те же значения при update, что и до "входа" в режим редактирования.

Если в отношении клиентской стороны (т.е. sql запросов) можно выбирать - класть болт на изменения или наоборот, их учитывать, то в отношении конкурирующих транзакций сервер поступает всегда единообразно, так, как в нем была реализована модель обработки таких конфликтов.

Также, не надо забывать, что транзакция snapshot при получении конфликта конкурентного update хоть в wait, хоть в nowait, не может "повторить update", т.к. в силу своего уровня изолированности она физически не может увидеть эти изменения, и соответственно, их переписать.

То есть, если для RC поведение Оракла еще бы имело смысл (например, типа, "давайте так же сделаем в ФБ"), то для snapshot - увы, никак и никогда. То есть, поведение обработки конфликта в ФБ в RC соответствует таковому в snapshot.
Однако, отлуп в ФБ в RC считается логичным, потому что если Б повисла на конфликте, то она до завершения А коммитом не в состоянии "увидеть" что изменила А. И это является индикацией, что до изменений Б кто-то уже успел запись изменить. Благо, как я уже сказал, RC по такой ошибке позволяет перечитать данные закоммиченные транзакцией А, и дальше решить, повторять update, или нет.