Если честно, мне никогда в жизни не приходило в голову использовать no_record_version. Для чтения списков документов-событий оно не надо, а действия, не справочный просмотр, со строкой всегда выполнял в снапшоте. Возможно я что-то упустил в этой жизни :)

Скажите мне ради бога что я всё неправильно понял и что вторая транзакция не перекроет обновление в первой автоматически.

Баба Яга категорически против если решение о перекрытии принимает не пользователь, поглядевши - а что там изменилось. И речь не только об изменении одного поля двумя транзакциями. На принятие решения в общем случае влияют и другие поля.

Да, есть случаи когда это не только допустимо, но и удобно. Но не меньше случаев и когда недопустимо. На фоне управления типом RC транзакций чохом через конфиг это поле граблей в стране не только мнэээ... нубов.

Пользователь влияет на решение - актуальны его изменения после конфликта или нет. Когда речь о регистрации уже свершившегося факта - как говорится, нравится, не нравится, спи, моя красавица. Я тут как-то упоминал затяжное завершение много-много-позиционной складской операции. Если программировал гомосапиенс, то есть все изменения идут в приращениях, то применение для этого такой RC_RC вместо снапшота - это просто конфетка, снимающая серьёзный гемор. В руках же гомоэректуса - разрушительная сила. Когда же о планировании каких-то действий - бабушка надвое для всех гом. Скажем, резервирование товара на складе под планирующиеся отгрузки. Превышение количества резервов над имеющимся в наличии количеством - штука не так чтоб недопустимая, но нежелательная и требующая вдумчивого подхода. Скажем, отгрузка послезавтра, сегодня получается превышение. Но если человек знает, что завтра крест на пузе придёт ещё партия, то можно и рискнуть. Не каждый день фуры под Выборгом разбиваются. А если точно знает что не придёт, то утрётся или согласует с коллегой кому нужнее. Простейшее влияние другого поля - один формирует количество в отгрузке, другой меняет дату по объективным, не зависящим ни от одного ни от другого причинам. Правда, если он её изменит после формирования, то первый этого тоже не заметит или заметит поздно :) Ну, в общем-то, да, можно конечно по старинке вести все изменения в снапшотах и Read Commited как таковой пользовать для изменений в исключительных, хорошо продуманных случаях, тут вы с Григорием правы, но те же хранимые агрегаты если ведутся на лету, то триггерами в снапшотах, изменяющих "первичку". Короче, без переформатирования мозгов не обойтись, надо с этой мыселью переспать :)