Одновременное редактирование записи

[Kirvisniemi]

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

С точки зрения программы, которая отвечает за изменения в базе (СУБД), без разницы что там и куда заносят. Одновременно это все равно не происходит, т.к. кто изменил данные раньше, кто-то позже (пусть даже на пару микросекунд). Поэтому собственно и проблем никаких нет.

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

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

В общем все эти блокировки формально разделились на две части. Первая часть подразумевала оптимистическую работу с базой, вторая пессиместическую.

Оптимистическая параллельная работа (optimistic concurrency - обычно это словосочетание ошибочно переводят как оптимистическая конкуренция) предполагает отсутствие блокировок и проверку на конфликты только при изменении данных. Т.е. оптимистично предполагается, что пользователь, который открыл карточку клиента изменять ее не будет.
Пессимистическая параллельная работа подразумевает блокировку, т.е. пессимистично предполагается, что пользователь будет изменять карточку, поэтому он будет работает с ней в монопольном исключительном режиме.

Разные СУБД допускают (или не допускают) разные уровни блокировок и вид параллельной работы. 1С 7.x, например, допускает работу в пессимистическом режиме. Navision в оптимистическом. Сам же SQL Server имеет множество видов блокировок, которые настраиваются через т.н. уровни изоляции и тип курсоров.

В Navi, проверка на изменение записи делается по разному, в зависимости от типа базы SQL или native.

Если SQL, то проверка изменений делается на основе datetime-штампов. Если native, то чере механизм версий.

Как отследить.
Во-первых, SQL Server сам ведет логи (при включенном аудите) - кто, в какое время и какую именно транзацию сгенерировал. Во-вторых, сам Navision при ручном изменении данных каким либо пользователем вызывает один из триггеров OnGlobalChange, OnGlobalModify или OnGlobalInsert из кодюнита 1.
В зависимости от настроек, содержащихся в таблицах Change Log Setup, Change Log Setup (Table) и Change Log Setup (Field), в таблицу Change Log Entry пишется или не пишется лог пользовательских операций.
Настройки, как уже правильно сказали, можно изменять через Финансы->Настройка