Не получается сформировать рендж с помощью strFmt

[Dronas]

Замена NoYes на 0 или 1 спасла ситуацию

[DSPIC]

Правильно, ведь enum в SQL = это int
=> enum2int(NoYes::Yes).

[gl00mie]

Цитата:

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

Правильно, ведь enum в SQL = это int
=> enum2int(NoYes::Yes).

Да ничего не правильно - парсер запросов в ядре должен сам переводить мнемонические обозначения значений енумов в числовые значения перед отправкой на SQL

[gl00mie]

Цитата:

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

Замена NoYes на 0 или 1 спасла ситуацию

Единственное, что приходит в голову, это что, возможно, поле ERG_RPDocument.SelectedDivergence не типа NoYes, а какого-то другого Был как-то раз аналогичный косяк с преобразованием значений enum'ов в запросах.

[DSPIC]

Однако, парcер не переводит NoYes::Yes в 1.
Продемонстрируйте на примере, где InventTable.PurchModel точно NoYes

static void Job(Args _args)
{
    InventTable             inventTable;
    QueryRun                qr;
    Query                   query = new Query();
    QueryBuildDataSource    qbds;
    QueryBuildRange         qbr;
    str                     rangeValue;
    ;

    qbds = query.addDataSource(tablenum(InventTable));

    qbr  = qbds.addRange(fieldnum(InventTable, RecId));

    rangeValue = strFmt("((ItemId==\"%1\") && (PurchModel==%2))", "B-R12",  enum2int(NoYes::Yes));

    qbr.value(rangeValue);

    qr = new QueryRun(query);

    while (qr.next())
    {
        inventTable = qr.get(tablenum(InventTable));

        info(strFmt("%1 - %2", inventTable.ItemId, inventTable.PurchModel));
    }
}

[gl00mie]

Цитата:

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

Однако, парcер не переводит NoYes::Yes в 1

В ходе формирования запроса есть два этапа: 1) - формирование запроса на «внутреннем» аксаптовском SQL, в ходе которого для тех же enum-значений подставляются мнемонические обозначения - значения меток соовт. значений enum для текущего выбранного языка (в частности, для NoYes::Yes и русского языка подставится "Да" без кавычек); 2) преобразование запроса в "родной" SQL, который уже непосредтвенно отсылается на СУБД. На втором этапе парсер запросов преобразует enum-значения в запросе из текста меток в соотв. числовые значения, и именно это я имел в виду в первоначальном сообщении. Результаты второго этапа, очевидно, можно продемонстрировать только с помощью трассировки SQL-запросов.

Цитата:

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

Продемонстрируйте на примере, где InventTable.PurchModel точно NoYes

Если под примером подразумевалась строка

info(strFmt("%1 - %2", inventTable.ItemId, inventTable.PurchModel));

то должен разочаровать: strfmt() и парсер запросов суть вещи разные. А на счет демонстрации - извольте:

PS В привеленном примере я поменял код номенклатуры и включил литералы в запросе.

[AndyD]

Цитата:

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

1) - формирование запроса на «внутреннем» аксаптовском SQL, в ходе которого для тех же enum-значений подставляются мнемонические обозначения - значения меток соовт. значений enum для текущего выбранного языка (в частности, для NoYes::Yes и русского языка подставится "Да" без кавычек); 2) преобразование запроса в "родной" SQL, который уже непосредтвенно отсылается на СУБД.

По-моему, стоит разделять визуализацию запроса и его внутреннее хранение.

Внутри запроса хранится числовое представление енума.
При визуализации (при вызове toString()) проверяется в каком виде этот енум попал в запрос (в виде числа, метки или названия значения) и в этом-же виде показывается. Эта информация хранится только для текущего экземпляра Query и, к примеру, при перепаковке запроса не сохраняется

[gl00mie]

Цитата:

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

По-моему, стоит разделять визуализацию запроса и его внутреннее хранение. Внутри запроса хранится числовое представление енума.

Хорошо, если так, но в эту схему не совсем вписываются такие эффекты, как в следующей теме:
Теряется фильтр из-за того, что не задан label
если бы "внутри" запросов все было так кошерно, то откуда бы взялась завязка на метку значения enum? Мне кажется, одной визуализацией это объяснить сложно.

[ZVV]

Спасибо отдельное землякам за тестовый пример, который и мне и автору видимо было лень писать.

Я тут с ним поигрался чуток:

static void Job(Args _args)
{
    InventTable             inventTable;
    QueryRun                qr;
    Query                   query = new Query();
    QueryBuildDataSource    qbds;
    QueryBuildRange         qbr,qbr1,qbr2;
    str                     rangeValue;
    ;

    qbds = query.addDataSource(tablenum(InventTable));

    qbr  = qbds.addRange(fieldnum(InventTable, RecId));

    qbr1  = qbds.addRange(fieldnum(InventTable, ItemId));
    qbr2  = qbds.addRange(fieldnum(InventTable, PurchModel));


    rangeValue = strFmt('%1.ItemId=="%2" && %1.PurchModel==%3', qbds.name(), "01810_К093",  NoYes::No);
    qbr.value(rangeValue);
    info(qbds.toString());
    rangeValue = strFmt('%1.ItemId=="%2" && (%1.PurchModel==%3)', qbds.name(), "01810_К093",  NoYes::No);
    qbr.value(rangeValue);
    info(qbds.toString());
    rangeValue = strFmt('(%1.ItemId=="%2") && (%1.PurchModel==%3)', qbds.name(), "01810_К093",  NoYes::No);
    qbr.value(rangeValue);
    info(qbds.toString());
    rangeValue = strFmt('(%1.ItemId=="%2" && %1.PurchModel==%3)', qbds.name(), "01810_К093",  NoYes::No);
    qbr.value(rangeValue);
    info(qbds.toString());
    rangeValue = strFmt('((%1.ItemId=="%2") && (%1.PurchModel==%3))', qbds.name(), "01810_К093",  NoYes::No);
    qbr.value(rangeValue);
    info(qbds.toString());

    qbr.value("");
    qbr1.value(queryValue("01810_К093"));
    qbr2.value(queryValue(NoYes::No));
    info(qbds.toString());

    qr = new QueryRun(query);

    return;

    while (qr.next())
    {
        inventTable = qr.get(tablenum(InventTable));

        info(strFmt("%1 - %2", inventTable.ItemId, inventTable.PurchModel));
    }
}

Рекомендую и вам попробовать позапускать разные варианты.

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

SELECT * FROM InventTable WHERE (((RecId = 0)))

, чем видимо и объяснялось то, что у автора "Так работало". На самом деле оно работало совсем не так.
- парсер действительно не парсит в таких рэнджах значения енумов, а только в обычных, "человеческих" рэнджах... А в этой ситуации всё-таки нужно указывать реальное цифровое значение енума.
- ситуация с тем, что внутренее название датасорсов для такого случая отличается, действительно имеет место в таких случаях:

SELECT * FROM InventTable WHERE (((InventTable_1.ItemId=="01810_К093")....

, что, правда, не мешает этому запросу нормально обрабатываться. (если остальное всё ОК)

PS запускал на 3.0 сп3 кр3
PS1 и, кстати, на этой версии нету функции "enum2int"

update: PS2 под "позапускать", я подразумеваю позапускать различные варианты указанных рэнджей в джобе на исполнение запроса (без return)... при этом включить трейс и отслеживать получающийся SQL...

[Dronas]

Цитата:

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

Единственное, что приходит в голову, это что, возможно, поле ERG_RPDocument.SelectedDivergence не типа NoYes, а какого-то другого Был как-то раз аналогичный косяк с преобразованием значений enum'ов в запросах.

Оно NoYesId