Kashperuk Ivan: Tutorial: refresh, reread, research, executeQuery - which one to use?

[kashperuk]

research(true) потому так намного быстрее и работает, что работает напрямую с гридом (по сравнению с findRecord).

[Logger]

Цитата:

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

research(true) потому так намного быстрее и работает, что работает напрямую с гридом (по сравнению с findRecord).

В 2009-й не заметил особой разницы.
Более того воспроизвелся один неприятный глюк (живет еще с 3-ки)

Пример.
1. Пользователь отфильтровал форму заказов по чекбоксу в гриде.
2. Жмет кнопку которая делает некую обработку с заказом, в результате которой галка снимается, таким образом заказ перестает попадать в выборку.
3. После обработки автоматом вызывается salesTable_ds.research(true); (раньше было salesTable_ds.research(); salesTable_ds.findRecord(common_Before)

При исполнении ядро безуспешно пытается найти запись, затягивая все выборку заказов на клиент, сжирая всю оперативку на терминальном сервере.
70 тысяч заказов съели порядка 1 гига памяти.

Судя по поведению аксапты salesTable_ds.research(true); внутри себя все таки дергает findRecord или аналогичный код.

Проблему удалось решить только за счет использования

        element.args().lookupField(fieldNum(SalesTable, salesID));
        element.args().lookupValue(locSalesId);

правда чтобы такой поиск заработал корректно пришлось сбрасывать пользовательские сортировки на форме. Иначе может некорректно позиционироваться.

Можно еще было обязательно ограничивать выборку заказов с тем чтобы даже при таком глюке с базы не затягивалась большая выборка. Но это дело вкуса - кому что удобнее.

P.S.
Глюк в ядре немного странно себя ведет. Так как если в моем примере галка не снимается а ставится, то затягивания все выборки заказов в память не происходит. Почему - пока не разобрался. Возможно дело в сортировках.