|
04.03.2003, 12:53 | #1 |
Moderator
|
LineNum
Добрый день.
Есть такие таблицы, как InventJournalTrans, SalesLine. У них есть поле LineNum, которое заполняется по довольно интересному алгоритму. Возьмем одну таблицу InventJournalTrans, а точнее форму с аналогичным названием. При создании строк lineNum автоматически формируется. А вот где это происходит ??? Беглый поиск по исходному коду ничего не дал. Но зато, на датасоурсе в той же форме InventJournalTrans я нашел свойство counterField = LineNum. И что-то у меня закралось подозрение, что кода формирующего lineNum я не увижу, так как этот код прописан глубоко в ядре, а все чем я могу играться это тот самы counterField. Это так или нет ? Если я прав, как пользоваться этим counterField ? Если нет, где этот код ? Заранее благодарю. |
|
25.06.2007, 19:30 | #2 |
Участник
|
Наступил на вот такие грабли:
В DS формы свойство CounterField установлено как LineNum. Строк в документе 760. В результате «хитрого» стечения обстоятельств часть строк получили одинаковый LineNum. Это в свою очередь привело к тому, что при разноске документа, у меня пошли некорректные суммы. Прогнал job и сделал уникальным LineNum для этого документа, суммы сошлись. Приложение сильно модифицированное, но что-то мне кажется, что при таких раскладах и в стандарте была бы ошибка. Кто-то еще сталкивался с такой проблемой? |
|
26.06.2007, 09:35 | #3 |
Участник
|
Как они могут получить одинаковый LineNum? ведь первичный ключ должен закрывать эту возможность - JournalNum, LineNum
|
|
26.06.2007, 09:38 | #4 |
Участник
|
Скорее всего, LineNum там все-таки разный, но отличается в пятом-шестом-седьмом знаках. Аксапта показывает округленные значения. Но на сравнение все равно влияют все значящие цифры. Скорее всего, причина бага в другом.
|
|
26.06.2007, 10:51 | #5 |
Участник
|
Цитата:
Цитата:
X++: 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)); } } После того как job-ом сделали уникальным LineNum в рамках ParentRecId, проблема исчезла. |
|
18.03.2016, 11:31 | #6 |
Участник
|
Коллеги, добрый день! Возможно, кому-то будет интересно. При разборе собственных авгиевых конюшен, столкнулись со следующим эффектом (воспроизводится на DAX2009, в частности):
если в форме с заказами несколько раз создать строки без сохранения данных в БД, то нумерация таких (не сохранённых) строк правильная. Срабатывает свойство CounterField на источнике данных SalesLine. Далее, начинаем прописывать код номенклатуры и пр. в созданные "болванки", сохраняем строки в БД. При этом видим: номер строки во всех создаваемых строках равен максимальному номеру строки созданного нами массива "болванок". В результате получаем строки с одинаковыми номерами. Причём, уникальный индекс, который содержит SalesLine.LineNum (SalesLineIdx) позволяет такую штуку, поскольку в него входит ещё и RecId. Может быть, кто-нибудь знает, как этот момент красиво обойти?
__________________
MS Dynamics AX 2009 Kernel 5.0.1600.4110 Application 5.0.1500.6491 |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
18.03.2016, 16:13 | #7 |
Участник
|
Цитата:
Запись не сохраняется при переходе на другую в гриде Т.е. в метод Create() на SalesLine в источнике данных формы в конце после super() добавить команду X++: this.forceWrite(true) Правда, тогда невозможно будет делать болванки без сохранения
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: Sergey Petrov (1). |