Цитата:
Сообщение от
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 или аналогичный код.
Проблему удалось решить только за счет использования
X++:
element.args().lookupField(fieldNum(SalesTable, salesID));
element.args().lookupValue(locSalesId);правда чтобы такой поиск заработал корректно пришлось сбрасывать пользовательские сортировки на форме. Иначе может некорректно позиционироваться.
Можно еще было обязательно ограничивать выборку заказов с тем чтобы даже при таком глюке с базы не затягивалась большая выборка. Но это дело вкуса - кому что удобнее.
P.S.
Глюк в ядре немного странно себя ведет. Так как если в моем примере галка не снимается а ставится, то затягивания все выборки заказов в память не происходит. Почему - пока не разобрался. Возможно дело в сортировках.