Цитата:
Сообщение от
RedFox
Полной блокировки нет, особенно на SQL (например там блокируется всего несколько записей, а не вся таблица). И при код может дойти до нахождения последнего номера, получить его, а потом откатиться.
Цитата:
Сообщение от
Alterant
Это не так. На SQL конструкцией:
Table.Locktable;
Table.Find('+');
тоже блокируется весь диапазон.
COMMITа в учетном коде до завершения быть не должно, поэтому ситуация довольно странная.
Как мне представляется блокируются несколько записей, а не диапазон.
Начиная с момента выполнения кода:
Table.Locktabe;
Table.find('+');
и до commit'a или отката транзакции другие клиенты Нава, выполняющие тот же код будут ждать окончания блокировки ПОСЛЕДНЕЙ записи на команде find('+'), и неважно чем закончиться блокирующий процесс - откатом транзакции или коммитом. В любом случае следующий процесс прочитает последний номер операции.
При таком построении кода гарантируется уникальность и отсутствие пропусков в номерах операций при многопользовательской работе.
Думаю стоит копать в сторону инкремента NextEntryNo без вставки в 17 таблицу.
Для начала посмотрите фин. регистры возможно номера отсутствующих операций лежат в диапазоне одной операции учета.
PS. NAV 50SP1 и Nav Express не видел, однако объемы изощренного RU кода начиная с 4.0 SP2 растут в 12 cu с пугающей меня быстротой.