Ошибка в нумерации строк журналов

[kia]

По непонятным мне причинам периодически идет сбой в нумерации строк журналов.
В моем случае это таблица RHRMOrderTrans поле LineNum.
Номера повторяются в пределах одного журнала. В результате при проведении имеем ошибку: Ключ с именем 0,00 уже существует.
Каковы могут быть причины и как это править?

[DSPIC]

1. За автонумерацию строк на на форме отвечает свойство "CounterField" на датасорсе формы. В нем указывается, какое поле автонумеровать. За это отвечает внутренний механиз форм. Новое значение вроде генерится в методе initValue на датосорсе.
2. Но часто строки создаются не на форме, а из кода. В этом случае, алгоритм по автонумерованию строк ложится на плечи программиста.

Как отловить? Если это форма, то можно попробовать вывести lineNum в грид и следить за ним в моменты инициализации и сохранения строки. Думаю, дубликат не сложно будет заметить, а главное - в какой момент он появляется - при создании строки - либо при сохранении. А там уже искать грабли в методах (если это не движок виноват)

Если это не форма, или визуально следить не просто, то вставлять в код затычки и отслеживать то же самое с помощью кода. Т.е. нужно определить момент, когда происходит некорректное формирование lineNum.

[ViV]

Возможно ваш случай.
Дублирование LineNum в строках журналов

[kia]

Цитата:

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

Возможно ваш случай.
Дублирование LineNum в строках журналов

Да, случай мой, но нигде я пока не встретил вариант решения этой "извествой" проблемы.
Насколько я понял, значение номера строки формируется в классe JournalTransData.
Но почему и как возникают дубли (и дробные значения) я так и не понял.
Можно попробовать сделать уникальность по Журналу и Номеру строки. Так хоть получим ошибку сразу при вставке, а не потом.
Но хочется исключить в принципе подобный случай.

[Zabr]

Цитата:

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

(и дробные значения)

Это-то как раз стандартное поведение. Если у вас курсор стоит на строке N и вы вставляете новую запись, то она может получить дробный номер, равный среднеарифметическому между строками N-1 и N. Например, строчка между 1 и 2 получит номер 1,50, а следующая вставленная между 1 и 1,50 получит номер 1,25 и т.д.
А вот почему возникают дубли - нужно смотреть конкретный журнал. Возможно, дубли как-то возникают при одновременной работе в одном журнале нескольких человек. Простой способ избежать еще на этапе создания строк - сделать уникальный индекс с кодом журнала и номером строки.

[ZVV]

Цитата:

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

Да, случай мой, но нигде я пока не встретил вариант решения этой "извествой" проблемы.
Насколько я понял, значение номера строки формируется в классe JournalTransData.
Но почему и как возникают дубли (и дробные значения) я так и не понял.
Можно попробовать сделать уникальность по Журналу и Номеру строки. Так хоть получим ошибку сразу при вставке, а не потом.
Но хочется исключить в принципе подобный случай.

Счас Аксапты под рукой нет, но, насколько я помню, эта "известная" проблема очень легко воспроизводится: отфильтруйте часть строк журнала (с меньшими номерами), а потом добавьте новую запись в конец списка.
Суть в том, что этот движок автонумерации на форме работает не с таблицей, а с датасорсом, и, соответсвенно, при попытках дать новой строке номер он отталкивается от того, что есть в данный момент в этом датасорсе. А если он отфильтрован, то часть строк при этом не учитывается - вот и появляются дубликаты...
Как-то вот так...

Ну и как уже сказали, "исключить в принципе подобный случай" проще всего уникальным индексом...
Есть, конечно, и более сложный и гораздо менее эффективный способ - "докодировать" нужные проверки и/или движок автонумерации.

[kia]

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