Позиционирование на конкретную запись датасета

[Lucky13]

Требуется после обновления формы спозиционировать курсор на конкретную запись датасета. Использую следующий код

PHP код:

element.args().lookupField(FieldNum(Table, Field));
element.args().lookupValue(Value);
ds.research(); 


Все работает правильно и быстро, но если в поле Field несколько значений Value, то курсор позиционируется на первую из них, хотя при переходе к основной таблице курсор позиционируется на нужную запись по значениям не одного, а двух полей.
Метод findRecord дает нужный результат, но в отличии от перехода к основной таблице работает намного медленнее чем переход к основной таблице.
Подскажите, пожалуйста, как решить данную проблему

[Dron AKA andy]

Цитата:

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

... в поле Field несколько значений Value ...
...хотя при переходе к основной таблице курсор позиционируется на нужную запись по значениям не одного, а двух полей ...

Не очень-то понятно. Несколько значений в одном поле, переход к основной таблице по 2-м полям (стоите-то и нажимаете "Перейти" на одном каком-то поле) ...

[Lucky13]

Пример:
Если стоять на строке заказа и перейти к таблицы партий, то, если есть несколько записей с одинаковым номером партии и разными ItemId, произойдет переход на нужную партию (эта строка будет вверху) и курсор будет стоять на строке, соответствующей выбранному ItemId. В принципе логично, т.к. в InventBatch уникальный индекс по двум полям (InventBatchId и ItemId), но сделать подобное позиционирование не получается. Выше указанный способ позиционирует либо по номеру партии, либо по ItemId, а вместе не получается.

[AndyD]

Неправильно вы думаете.

Посмотрите метод run() формы InventBatch - вам станет понятно.

[AndyD]

Axapta хитрая.

Вот что происходит при переходе к основной таблице (принцип которого у вас используется в коде).

1. На сервере открывается курсор для такого запроса

select * 
frrom Table 
where Table.Field >= Value ...

где Table.Field - поле с которого произошел переход (или точнее LookupField() в args() формы)
Value - значение поля с которого произошел переход (или точнее LookupValue() в args() формы)
В буфер на клиенте выбирается некоторое количество записей (зависит от таблицы).
2. Курсор позиционируется на первой записи.

При перемещении назад по датасету (нажав PgUp, Up или вызвав сооответствующий метод) на сервере открывается курсор для такого запроса

select * 
frrom Table 
where Table.Key1 < Value ...

При этом для ORDER BY включается обратный порядок сортировки.
Строки в буфер на клиенте добавляются в обратном порядке.

Дальше при перемещении вперед или назад по датасоурсу, если не получены все строки с сервера, фетчится соответствующий открытый курсор.

При таком алгоритме работы Axpata'ы, если включить сортировку на табличной форме не по ключу перехода, то будет неправильно позиционироваться курсор после открытия формы

В форме InventBatch фактически выполняется перемещение по датасорсу ч/з ds.Next(), пока не найден нужный ItemId (InventBatch отпозиционирован движком по приведенному алгоритму).

[Lucky13]

А не подскажите что это за класс InventDimJumpRefEngine_RU. Что он делает и как им пользоваться?

[Dron AKA andy]

Он делает именно то, что обозначено в его названии. Это семейство классов - движок для реализации перехода к основной таблице на полях складской аналитики. Как им пользоваться - можно посмотреть на приведенной выше форме InventBatch или на других формах складских аналитик.

[Garic]

Лучше им не пользоваться или доделать. Если у вас много записей в табличке (что нормально для inventBatch), то форма может открываться минутами (у нас было до 5-ти минут). Из-за этого позиционирования.

[Garic]

InventDimJumpRefEngine_RU - findRecord

        while (cursor.RecId                                 &&
               cursor.RecId                   != prev.RecId &&
               cursor.(this.curFilterField()) != this.callerFilter())
        {
            prev = cursor.data();
            dataSource.next();
        }

Угадайте сколько подобный код будет лазить по записям .это появилось в SP2.
До этого было не лучше - использовался findRecord.
Лучше уж просто фильтры ставить.