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

[барбудас]

Объясните плз механизм "оптимистич. режима" в Навижн!

Проблема такая. Пользователь получает сообщение что кто-то другой изменил запись. Исходя из документации, это нормально, пользователь теряет введенные данные, ему очень обидно...
Хотелось бы знать:
* как можно отследить, КТО был тот "другой" (ибо все это очень подозрительно в 9 то часов вечера).
* как устроен сам механизм, т.е. как осущ. проверка того, что запись была изменена (любопытсво человека, который сам пытается проектировать универсальные ИС).

Спасибо.

[Yoil]

Отследить можно с помощью журнала изменений (финансы - настройка - журнал изменений. Предварительно его нужно настроить финансы - настройка - журнал изменений настройка).

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

[Likefire]

Есть такая переменная - USERID. На процедуру изменения записи навесить код, отображающий в вашем сообщении логин того, кто изменял. USERID - и есть логин Navision (логин БД или Windows-логин,- без разницы).

[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 пишется или не пишется лог пользовательских операций.
Настройки, как уже правильно сказали, можно изменять через Финансы->Настройка

[Shoorik]

Цитата:

Сообщение от барбудас

* как устроен сам механизм, т.е. как осущ. проверка того, что запись была изменена (любопытсво человека, который сам пытается проектировать универсальные ИС).

А любопытство в какой-то мере может быть удовлетворено знакомством с теоретическими основами организации многоверсионных данных. Можно почитать, например, вот эту статью: OSP.RU

[барбудас]

Спасибо всем большое.