Проблемы с отображением скл. аналитик

[ZVV]

Добрый день.

Есть проблема с отображением складских аналитик, в частности на форме Заказов.

Ситуация примерно следующая:
Имеем аналитику "размер". По ней включено отображение в гриде строк заказа. Время от времени появляется такая ситуация (стоит ли говорить, что сделать стабильно повторяемый тест-кейс не удаётся ) -- при скроллировании строк заказа на какой-то из строчек отображается не тот размер, который реально лежит в БД! Это установлено точно. При этом если пользователь что-то в строке поменяет (не размер), то, естественно, в базу сохранится уже новый, неправильный размер.
Причины такого поведения не известны и, возможно, ситуация может повторяться и для других аналитик и на других формах, т.к. маханизм везде стандартный.
Может это зависит от скорости отрисовки формы, кол-ва записей, или ещё чего... непонятно.

Никто не сталкивался с таким? Чем может быть вызвано? Или может это баг и лечится одним из обновлений?

версия 3.0 SP2 KU1 Build #9.3+ Oracle 9.2.0.8

Спасибо!

[mazzy]

Цитата:

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

Никто не сталкивался с таким? Чем может быть вызвано? Или может это баг и лечится одним из обновлений?

Сталкивался. Это почти ФАКовый вопрос.

Если несколько таблиц отображаются в одном Join'е, то между ними ни в коем случае не должно быть тип связывания Delayed Join.

Кто-то установил у таблицы InventDim тип связывания Delayed.
Либо сильно-сильно и неправильно напрогал метод Update у датасорса этой таблицы.

[ZVV]

Спасибо, Маззи, но это было бы слишком просто...

Форма SalesTable. Связывание между SalesLine & InventDim никто не менял, стоит стандартные InnerJoin + DelayActive=No.

Апдэйты и врайты тоже "нетроганы"... К тому же я ж говорю, проблема начинается ещё на отображении, а не на сохранении. Поэтому предполагаю, что баг именно в связывании и/или обновлении/отображении на форме..

Так что вопрос остаётся в силе.

[Sada]

Значит так. В методе ExecuteQuery таблицы SalesTAble после супера напишите строку кода
info(this.query().datasourceNo(1).tostring());
И постите здесь получившийся селект. Всё станет сразу ясно.

[ZVV]

На SalesTable

SELECT * FROM SalesTable USING INDEX SalesIdx

На SalesLine

SELECT * FROM SalesLine USING INDEX SalesLineIdx 
WHERE SalesTable.SalesId=SalesLine.SalesId 
JOIN * FROM InventDim 
WHERE SalesLine.InventDimId = InventDim.inventDimId

[Sada]

Хмм... Вроде всё хорошо. Хотелось бы увидеть целиком запрос со всеми таблицами и посмотреть на джоины всякие.

[ZVV]

Не совсем понял что Вы хотите увидеть? Уточните, пожалуйста?

Как связаны таблицы я написал выше, селекты привёл. Или Вы имеете ввиду непосредственно запросы идущие к БД?

Все джоины между датасорсами на форме стандартные, нами не менялись.

[Sada]

Ну если всё стандартное, тогда я не знаю... Остается тока лезть в метод updateDesign на форме и дебажить дебажить дебажить

[ZVV]

Как я уже говорил, есть одна маленькая сложность - невоспроизводимость...

Сам видел такое только 2 раза, но у пользователей этих не было прав дебагить... :-\
Но у пользователей повторяется регулярно...

Ещё один момент - есть подозрение, что такое происходит только под определёнными группами пользователей, а под админом - никогда. Но это на уровне одной из версий. Фантазии предположить как на это могут повлиять права не хватает...

[Raven Melancholic]

Цитата:

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

Как я уже говорил, есть одна маленькая сложность - невоспроизводимость.

А эта ошибка проявляется не тогда, когда более 28 строк на каждой 29? У нас такая штука с закупками была. Так и не выяснили причину и пошли по методу грубой силы - в Active проверяем равен ли InventDimId на строке закупки и в InventDim и если есть различие, то грубо устанавливаем в PurchLine InventDimId из InventDim. Жутко некрасиво, но бага пропала.

[ZVV]

Цитата:

Сообщение от Raven Melancholic

А эта ошибка проявляется не тогда, когда более 28 строк на каждой 29? У нас такая штука с закупками была. Так и не выяснили причину и пошли по методу грубой силы - в Active проверяем равен ли InventDimId на строке закупки и в InventDim и если есть различие, то грубо устанавливаем в PurchLine InventDimId из InventDim. Жутко некрасиво, но бага пропала.

Только я вообще-то думал наоборот. Проблема то в том, что в курсоре InventDim лежит неправильная строка. Т.е. грубо перебить нужно именно её по реальному SalesLine.InventDimId

ЗЫ Только что поступили новости. Удалось повторить это под Админом.
Так что вероятно доступ по записям тут не при чём...
Прошёлся дебагом по "активу". Так и есть! В SalesLine аналитика одна, в InventDim лежит другое.
Грустно, вся вера в аксапту подорвана
Что ж теперь все формы с аналитикой костылями затыкать?!

[Sada]

Тогда остается только гадать... Доступ на уравне записей?

[KiselevSA]

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

[Sada]

Цитата:

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

А вот интересно, как отображается аналитика, если со строкой заказа связано несколько проводок с разными аналитиками?

я думаю дело не в этом. На форме отображается аналитика из salesLine.InventDimId. И InventTrans тут не причём.

[ZVV]

2 KiselevSA
ИнвентТранс тут не при чём, т.к. это аналитика по строке...

2 Raven Melancholic
Такой вариант решения уже давно вертится на кончиках пальцев, но что-то уж больно некрасиво, но всё идёт к нему.
Насчёт 28-29, нет, есть списки гораздо длиннее, но ошибки нет... Система к сожалению не просматривается...

2 Sada
В точку. Доступ на уровне записей есть. На InventDim, по складам...
Как это может давать такой эффект??

[Sada]

Цитата:

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

Доступ на уровне записей есть. На InventDim, по складам...
Как это может давать такой эффект??

А вот тут я не знаю...

[Sada]

Форма сильно модифицирована? Выложили бы проектом яб её посмотрел. Не важно что у меня нет того что у Вас. Есть мыслишки...

[fedka]

Кто-то решил данную проблему? На сколько вообще она часто встречается?
У нас Сп3 воспроизводится очень часто в заказах уже года 3.

[ZVV]

Цитата:

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

Кто-то решил данную проблему? На сколько вообще она часто встречается?
У нас Сп3 воспроизводится очень часто в заказах уже года 3.

Ну как решили.... Пришлось просто заткнуть костылём на active(). Если не ошибаюсь, просто вставил проверку на то, что инвентДим соответствует salesLine.InventDimId.. Если нет, то "перечитать" InventDim. Могу привести конкретный код завтра, если нужно, но он не сложный, думаю и так понятно.
Единственный момент, что это проблема не только формы заказов, а отмечались подобные баги и на CRM-предложениях и на закупках. Так что "затыкать" нужно и там тоже, на всех подобных формах...
Хотя в складских журналах вроде с таким пока не сталкивался. Или просто не попадплось.

[fedka]

Цитата:

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

Могу привести конкретный код завтра, если нужно, но он не сложный, думаю и так понятно.

Спасибо за ответ! Если не сложно, то напишите этот код!
Если это таже проблема, что и у нас, то:
У нас также навешена(ы) проверка(и) на форме заказов, но как они тогда сделаны... Менеджеры меняют цены или ставят немедленную и как раз на 24-26 строке начинается... (Конечно с номером строки это никак не связано, если расширить по вертикали форму строчек, то эффекта если не вру такого не видно).
Как только система видит данный эффект, то ругается грязно, после чего менеджерам надо закрыть форму.
Консультанты нам сказали, что это баг ядра. недавно я попробовал с клиентом и аосом SP6 (приложение SP3), тот же эффект!
Да и в 2х-уровневой эффект не проявляется, но я думаю всего лишь из-за того, что в 2х-уровневой форма заказов просто больше тормозит.
Поэтому, если не сложно приведите ваши изменения! Я не программист, но сегодня еще раз посмотрю наши проверки и попробую Ваши!