LineNum

[Starling]

Наступил на вот такие грабли:
В DS формы свойство CounterField установлено как LineNum. Строк в документе 760. В результате «хитрого» стечения обстоятельств часть строк получили одинаковый LineNum. Это в свою очередь привело к тому, что при разноске документа, у меня пошли некорректные суммы.
Прогнал job и сделал уникальным LineNum для этого документа, суммы сошлись.
Приложение сильно модифицированное, но что-то мне кажется, что при таких раскладах и в стандарте была бы ошибка.
Кто-то еще сталкивался с такой проблемой?

[zinius]

Как они могут получить одинаковый LineNum? ведь первичный ключ должен закрывать эту возможность - JournalNum, LineNum

[mazzy]

Цитата:

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

часть строк получили одинаковый LineNum.

Цитата:

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

Как они могут получить одинаковый LineNum? ведь первичный ключ должен закрывать эту возможность - JournalNum, LineNum

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

[Starling]

Цитата:

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

Как они могут получить одинаковый LineNum? ведь первичный ключ должен закрывать эту возможность - JournalNum, LineNum

Могут. Форма CustFreeInvoice. Таблица CustInvoiceLine. Индекс ParentRecIdIdx AllowDuplicate = Yes. Других индексов нет.

Цитата:

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

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

Они были одинаковыми. Вот такой Job

static void Job157(Args _args)
{
    CustInvoiceLine custInvoiceLine;
    ;
    while select count(ReciD) from custInvoiceLine index hint ParentRecIdIdx group by LineNum
        where custInvoiceLine.ParentRecId == 8484848
    {
        if(custInvoiceLine.RecId > 1)
            warning(strFmt("%1", custInvoiceLine.RecId));
    }

}

Выдавал 2, 3, 7, я думаю в данном случае при group by округления не было.

Цитата:

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

Скорее всего, причина бага в другом.

После того как job-ом сделали уникальным LineNum в рамках ParentRecId, проблема исчезла.

[Sergey Petrov]

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

если в форме с заказами несколько раз создать строки без сохранения данных в БД, то нумерация таких (не сохранённых) строк правильная. Срабатывает свойство CounterField на источнике данных SalesLine.

Далее, начинаем прописывать код номенклатуры и пр. в созданные "болванки", сохраняем строки в БД. При этом видим: номер строки во всех создаваемых строках равен максимальному номеру строки созданного нами массива "болванок". В результате получаем строки с одинаковыми номерами. Причём, уникальный индекс, который содержит SalesLine.LineNum (SalesLineIdx) позволяет такую штуку, поскольку в него входит ещё и RecId.

Может быть, кто-нибудь знает, как этот момент красиво обойти?

[Владимир Максимов]

Цитата:

Сообщение от Sergey Petrov

если в форме с заказами несколько раз создать строки без сохранения данных в БД, то нумерация таких (не сохранённых) строк правильная. Срабатывает свойство CounterField на источнике данных SalesLine.

Не оно?

Запись не сохраняется при переходе на другую в гриде

Т.е. в метод Create() на SalesLine в источнике данных формы в конце после super() добавить команду

this.forceWrite(true)

Правда, тогда невозможно будет делать болванки без сохранения

[Sergey Petrov]

Цитата:

Сообщение от Владимир Максимов

...

Правда, тогда невозможно будет делать болванки без сохранения

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

Мы решили не очень элегантно, зато достаточно надёжно: инициируем значения в initValue() источника данных. Предварительно делаем контейнер с имеющимися номерами и развлекаемся с этим контейнером. А свойство CounterField у нас вообще пустое.