Пропуски в номерах операций

[Васыо]

Сегодня совершенно случайно заметил в Фин. Книге Операций, что номера операций идут с разрывами. NAV 50SP1. Вот пример (естественно сортировка по полю Операция Но.):
521706
521707
521709
521710
521712
521713
521715
521716
521718
521719
521721
521722
521724
521725
521727
521728
Руками ничего не удаляется. Учётные кодюниты в первозданном виде. Это нормально или нет?

[DA_NEAL]

Это нормально.

[Васыо]

Судя по базе с Кронусом - нормально. Но честно говоря это немного смущает. А почему так происходит?
С номерами транзакций такого быть не может?

[RedFox]

Цитата:

Сообщение от Васыо

Сегодня совершенно случайно заметил в Фин. Книге Операций, что номера операций идут с разрывами. NAV 50SP1. Вот пример (естественно сортировка по полю Операция Но.):
...
Руками ничего не удаляется. Учётные кодюниты в первозданном виде. Это нормально или нет?

Одновременный учёт нескольких пользователей с откатом одного учёте, который был ранее и такая ситуация реальна.

[GalaM]

А сами операции возникли при учете каких документов?

[GRIZZLY_imported]

Цитата:

Сообщение от RedFox

Одновременный учёт нескольких пользователей с откатом одного учёте, который был ранее и такая ситуация реальна.

Разве при учете не происходит блокирование всех записей таблицы G/L Entry вплоть до окончания учета?

[Васыо]

gala, проводки сделаны через фин журналы. судя по всему ответы в 12-ом кодюните.

[RedFox]

Цитата:

Сообщение от GRIZZLY

Разве при учете не происходит блокирование всех записей таблицы G/L Entry вплоть до окончания учета?

Полной блокировки нет, особенно на SQL (например там блокируется всего несколько записей, а не вся таблица). И при код может дойти до нахождения последнего номера, получить его, а потом откатиться.

[Alterant]

Цитата:

Сообщение от RedFox

Полной блокировки нет, особенно на SQL (например там блокируется всего несколько записей, а не вся таблица). И при код может дойти до нахождения последнего номера, получить его, а потом откатиться.

Это не так. На SQL конструкцией:
Table.Locktable;
Table.Find('+');
тоже блокируется весь диапазон.
COMMITа в учетном коде до завершения быть не должно, поэтому ситуация довольно странная.

[Васыо]

Кому интересно самостоятельно взглянуть - посмотрите на Cronus в последнем Nav Express. То же самое. На 3284 операции 256 пропусков.

[rmv]

Цитата:

Сообщение от 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 с пугающей меня быстротой.

[Alterant]

Цитата:

Сообщение от rmv

Как мне представляется блокируются несколько записей, а не диапазон.
Начиная с момента выполнения кода:
Table.Locktabe;
Table.find('+');
и до commit'a или отката транзакции другие клиенты Нава, выполняющие тот же код будут ждать окончания блокировки ПОСЛЕДНЕЙ записи на команде find('+')

Вы правы, я выразился не точно. Только одна поправка - блокируется как последняя запись, так и диапазон, находящийся за ней. Т.е. вставить запись с номером, превышающим номер последней записи, скажем, на миллион тоже не получится. Это я имел ввиду. А вот вставлять в начало или середину таблицы при такой блокировке вполне можно.