Цитата:
Сообщение от
kashperuk
Прежде всего, спасибо за то, что не остались просто " еще одному человеку, пожелавнему остаться неизвестным"
Страна должна знать своих героев
.
Как то неудачно засветился с комментариями...хм
Цитата:
Сообщение от
kashperuk
Теперь по делу:
А почему во втором способе восстанавливается только lookupField, а lookupValue остается с RecId?
.
После executeQuery lookupValue сбрасывается (или после super() в нем, перекрытом).
Цитата:
Сообщение от
kashperuk
Мне кажется, особенно учитывая, что форма вызывается новая, и args формируется здесь же, что по ветке с findRecord идти никогда не будет
.
Честно говоря, я тоже так думаю - просто не могу представить себе обработчик формы (логику обработчика), который при запуске использует позиционирование по lookup методам. Единственный - это механизм JumpRef - но в данном коде мы ему не мешаем..
Цитата:
Сообщение от
kashperuk
Завтра поищу по АОТ, чтобы утверждать наверняка.
.
Проверил у себя [ сильно перелопаченный retail от коруса] :
В основном Lookup используются в init'e для анализа включать фильтры , накладываемые на форме, или нет...
Единственна критическая форма - Addresses , с ипользованием linkActivate в случае открытия из vendTable...
К сожалению, нет сейчас appl под рукой - по памяти....
Цитата:
Сообщение от
AndyD
А почему вы считаете, что по lookupField( ) по RecId будет искать правильно?
В случае с SalesTable будет работать корректно, потому что большему salesId будет соответствовать больший recId (пока не перевалили на отрицательные recId!).
А, к примеру, InventTable. Там сортировка идет по itemId, и далеко не всегда большему itemId соответствует больший recId. И таких примеров по AOT можно привести массу
.
Насколько я понимаю, позиционирование идет самим движком, уже в выбранном и отсортированном ds [?]..Не вижу причин [но проверю обязательно - есть такая большая DB с отрицательными recId] почему бы ему (движку) искать не корректно... или имелось ввиду время позиционирования?
Цитата:
Сообщение от
kashperuk
Можно усложнить - найти индекс по которому отсортирован дс, проверить уникальный ли он, проверить состоит ли он из 1 поля и только в ежэтом случае лукапить. Иначе скатываться к тормозному варианту
.
Эксперементировал на эту тему до знакомства с tabax...Положительных результатов не получил - как то странно работают объекты AOT, отвечающие за анализ PrimaryKey и уникальность индекса.. ( нет appl под рукой - иначе бы запостил результаты и код job'a, который меня смутил)... Поэтому и остановился на варианте ,используемом в tabax.
Цитата:
Сообщение от
AndyD
Тогда надо формировать строку axpath опираясь не на recId, а на поля уникального индекса (если он есть, опять же).
А в случае recId корректнее все-таки поиск перебором.
.
В случае НЕуникальности RecId?