|
01.04.2015, 17:21 | #1 |
Участник
|
Ошибка записи в SalesParmSubLine
Доброго времени суток!
DAX2009. Заказ на продажу - Разноска накладной, в окне "Количество" выбираем "Отборочная накладная" - вылетает инфолог не могу записать в SalesParmSubLine, запись уже существует. Не буду перегружать инфой как всё это происходит, корень зла обнаружен в SalesFormLetter_Invoice.reselect(). В цикле формируются записи в SalesParmLine и SalesParmSubLine, и получается что создаются лишние записи, обычно 2 или 3. Всё дело в том, что вот какой там цикл: X++: while select forceplaceholders _salesParmTable where _salesParmTable.ParmId == salesParmUpdate.ParmId join forupdate _salesParmSubTable where _salesParmSubTable.ParmId == _salesParmTable.ParmId && _salesParmSubTable.TableRefId == _salesParmTable.TableRefId X++: _salesParmSubTable.doUpdate(); Честно говоря, до этого момента не знал о такой особенности. Специально отдельным джобом попробовал имитировать такую ситуацию, действительно, возникает лишняя итерация в while select, если происходит обновление записи. Причем, это возникает только если код выполняется на сервере, такой момент. Что я делаю не так, что алгоритм именно так отрабатывает? Специально проверил - код на стандартных слоях, т.е. нет "вмешательства" со стороны модификаций. Значит - что? Неправильное использование функциональности? Но то что приводит к красному инфологу "Ошибка записи"... Странно как-то, возникают мысли о P.S. Если в предформе изначально стоит количество "Отборочная накладная", такой ошибки не происходит, что логично, т.к. тут алгоритм по несколько другим путям отрабатывает. Объясните плиз, в чем тут подвох? |
|
03.04.2015, 09:49 | #2 |
Участник
|
Борьба продолжается ) Погуглил на предмет аналогичных проблем, выяснилось что подобный инфолог в некоторых ситуациях так или иначе вылазил, но судя по всему по каким-то другим причинам - во-первых, происходило это не только из-за установки значения "Количество" в "Отборочная накладная", а во-вторых, лечилось простой чисткой таблицы SalesParmSubLine.
Пока что довольствуемся такой вот заглушкой: X++: while select forceplaceholders _salesParmTable where _salesParmTable.ParmId == salesParmUpdate.ParmId join forupdate _salesParmSubTable where _salesParmSubTable.ParmId == _salesParmTable.ParmId && _salesParmSubTable.TableRefId == _salesParmTable.TableRefId { // bug fix --> if (prevRecId && (prevRecId == _salesParmSubTable.RecId)) { continue; } prevRecId = _salesParmSubTable.RecId; // bug fix <-- // остальной код ... Коллеги, неужели никто ни разу не сталкивался с таким поведением? Последний раз редактировалось FrolovAndy; 03.04.2015 в 09:52. |
|
|
За это сообщение автора поблагодарили: konfet (2), madm (1). |
09.01.2018, 15:48 | #3 |
Снова балуюсь косаптой :)
|
Думаю, именно так - баг, а точнее г*внокод в стандарте. Проявился в DAX 2009, именно при Ваших условиях (только при выборе "количество из отборочной накладной"). Чистка таблицы SalesParmSubTable также не помогла. Предложенный вами хотфикс проблему решил. Спасибо! Обожаю этот форум
__________________
Бесты и регарды! |
|