Lookup задваиваются значения

[SuperStar88]

Делаю Lookup на контроле формы (надо вывести все уникальные значения поля таблицы)

    SysTableLookup          sysTableLookup = SysTableLookup::newParameters(tablenum(VendTrans), this);
    Query                   query;
    QueryBuildDataSource    queryBuildDataSource;
    QueryBuildRange         queryBuildRange;
    ;

    query = new Query();
    queryBuildDataSource = query.addDataSource(tablenum(VendTrans));

    queryBuildDataSource.addSortField(fieldnum(VendTrans, FIELD));
    queryBuildDataSource.addGroupByField(fieldnum(VendTrans, FIELD));


    sysTableLookup.addLookupfield(fieldnum(VendTrans, FIELD));

    sysTableLookup.parmQuery(query);
    sysTableLookup.performFormLookup();

Когда значение в контроле пустое, то всё нормально, но когда там уже что-то выбрано, то появляется чуть ли не бесконечный скролинг со множеством повторяющимися значениями.
Как правильно это сделать?

[Logger]

Вроде был баг в какой-то из версий, когда в лукапах сбрасывался group by
Вроде бы можно было обойти если расположить метод лукапа не на поле датасорса а на контроле.
Но точно уже не помню.

[TasmanianDevil]

Стандартный SysTableLookup крайне криво работает с переданным запросом - если есть хоть одно пересечение м-ду полями группировки в запросе и полями в лукапе, группировка сбрасывается.
Вся "радость" происходит в buildSelectionList() , можете сравнить свой queryBuildDataSource в своем lookup() и в buildSelectionList() в конце его исполнения - будете удивлены (group by исчезнет).
Решение - контролировать добавление полей ТАМ на каждой итерации цикла на отсутствие их в queryBuildDataSource fields()

[ice]

Если не вдаваться в подробности решения технической проблемы, а решать бизнес задачу, то лукап по проводкам лучше не делать, а сделать по справочнику, где значения уникальны, и если есть потребность проверить участвовало ли данное значение в проводках, то проверить на этапе сохранения значения

[Logger]

Цитата:

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

Стандартный SysTableLookup крайне криво работает с переданным запросом - если есть хоть одно пересечение м-ду полями группировки в запросе и полями в лукапе, группировка сбрасывается.
Вся "радость" происходит в buildSelectionList() , можете сравнить свой queryBuildDataSource в своем lookup() и в buildSelectionList() в конце его исполнения - будете удивлены (group by исчезнет).
Решение - контролировать добавление полей ТАМ на каждой итерации цикла на отсутствие их в queryBuildDataSource fields()

На x++ фикс можно сделать ?

Мне казалось бага где-то в ядре сидит.

[bacardi]

Попробуйте добавить

sysTableLookup.parmUseLookupValue(false);

[Владимир Максимов]

Если поле Field - это ссылка на справочник, то можно сделать Query по этому справочнику и через Exists Join добавить ограничение на факт наличия проводки. Можно, кстати, параметризировать добавление Exists. Т.е. по дополнительному параметру или выдавать все записи справочника или только с ограничением

Если совсем уж ничего не поможет, то вместо Query, можно наполнить временную таблицу и через parmTmpBuffer() передать как источник данных LookUp

Хотя, все-таки соглашусь с ice. Если это действительно ссылка на справочник, то лучше не фильтровать выпадающий список, а проверять уже выбранное значение.

[TasmanianDevil]

Цитата:

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

На x++ фикс можно сделать ?.

А почему нет ?
SysTableLookup - открытый класс.

protected void buildSelectionList(Query _query)
{
    QueryBuildDataSource            queryBuildDataSource = _query.dataSourceTable(tableId);
    QueryBuildFieldList             selectedFields;
    boolean                         returnItem;
    str                             method;
    int                             fieldId;
    int                             i;

    //+ ТумОВ 02.12.2022
    boolean  fieldSelected(FieldId _id)
    {
        int     j;
        FieldId selectedFieldId;

        for( j = 1 ; j <= selectedFields.fieldCount() ; j++ )
        {
            selectedFieldId = selectedFields.field(j);

            if(selectedFieldId == _id) return true;
        }

        return false;
    };
    //- ТумОВ 02.12.2022

    if (!queryBuildDataSource)
    {
        return;
    }

    selectedFields = queryBuildDataSource.fields();

    for (i = 1; i <= conlen(lookupItems); i++)
    {
        [fieldId, returnItem, method] = conpeek(lookupItems, i);
        //
        // FieldId could be 0 if current element represents a display method used
        // to return values for a lookup column.
        // If fieldId is 0 then there is no sense to add it to the selection list of the query.
        //
        //+ ТумОВ 02.12.2022
        //todo А если, <censored>, поле уже выбрано как агрегат в ранее переданном запросе - на<censored> агрегацию ?
        //if (fieldId)
        if (fieldId && !fieldSelected(fieldId))
        //- ТумОВ 02.12.2022
        {
            queryBuildDataSource.addSelectionField(fieldId);
        }
    }
}

Цитата:

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

Мне казалось бага где-то в ядре сидит.

Внутри закрытого QueryBuildDataSource.addSelectionField(<код поля>, [<тип агрегации>)] - повторная передача поля в список выбираемых с типом агрегации по умолчанию сносит режим группировки у источника данных. Обходится вышеуказанным контролем на наличие добавляемого поля в списке полей выбора источника данных lookup-овского запроса.

[pitersky]

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

[TasmanianDevil]

Цитата:

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

лукап с группировкой решение очень плохое

Почему же ?
Задача ограничения списка выбора значений какого-либо классификатора по набору его "засветившихся" позиций из какой-то порции транзакционных данных - регулярно возникающая задача, решаемая при минимуме трудозатрат именно так

[Владимир Максимов]

Цитата:

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

Почему же ?
Задача ограничения списка выбора значений какого-либо классификатора по набору его "засветившихся" позиций из какой-то порции транзакционных данных - регулярно возникающая задача, решаемая при минимуме трудозатрат именно так

Решение не масштабируемое. Например, если попросят дополнительно вывести в Lookup расшифровку отобранного кода (название из классификатора).

Т.е. как решение "по быстрому", чтобы "отвязаться" - пойдет. Но позже, сам же будешь это все исправлять

[TasmanianDevil]

Цитата:

Сообщение от Владимир Максимов

если попросят дополнительно вывести в Lookup расшифровку отобранного кода (название из классификатора).

addLookupMethod() - и баба с возу, и волки сыты

[Raven Melancholic]

Для себя я как-то решил, что в таких программных лукапах, где есть группировка, использовать временные таблицы (конечно, в 2012 те, что TempDB) или вьюхи.

Конечно, можно программно заткнуть описанные в теме проблемы, но практически любое их таких решений выключает возможности хоть как-то влиять на скорострельность.
В общем, что-то сделано, вроде работает, но как оптимизировать скорость работы таких частичных "затычек" непонятно в принципе.

[pitersky]

Цитата:

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

Почему же ?
Задача ограничения списка выбора значений какого-либо классификатора по набору его "засветившихся" позиций из какой-то порции транзакционных данных - регулярно возникающая задача, решаемая при минимуме трудозатрат именно так

Ну вообще-то кмк решаться она должна через exists join классификатора и транзакций. Так и работать быстрее будет, и идеологически корректно