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

[Dronas]

range = qbdsJoin.addRange(fieldnum(RPDocument, RecId));
range.value(strFmt('%1.Field1==%2&&(%1.Field2=="")', qbdsJoin.name(), NoYes::Yes));

Так работает, как только скобок становится больше аксапта ругается

К примеру такой фокус уже не прокатывает

((%1.SelectedDivergence==%2)&&(%1.SelectedSuperVisor==""))

[ZVV]

Привет.
Лучше всего если Вы:
1. Приведёте конкретный пример (который можно скопировать и проверить)
2. Конкретно приведёте текст ошибки "Аксапты". (А скорее СУБД, насколько я понимаю)
3. Проверите SQL, который идёт к базе, и если по нему проблема не понятна, то тоже можно его привести сюда.
4. Приведёте Версию Аксапты и СУБД.

ЗЫ Это не конкретно по этому вопросу, а по любому подобному вопросу, если хотите получить ответ, то данные действия максимизируют вероятность его получения. Имхо.

[Dronas]

Таблица RPDocument
поля:
Field1 (NoYesId)
Field2 (EmplId)

при:

range.value(strFmt('%1.Field1==%2&&(%1.Field2=="")', qbdsJoin.name(), NoYes::Yes));

Всё работает, при добавлении скобок

'((%1.SelectedDivergence==%2)&&(%1.SelectedSupeVisor==""))'

Уже не работает, выдаёт:
SELECT * FROM ERG_RPDocument WHERE SalesPickingListJournalTable.PickingListId = ERG_RPDocument.PickingListId AND ((((ERG_RPDocument_1.SelectedDivergence==Да)&&(ERG_RPDocument_1.SelectedSupeVisor==""))))
Ошибка расширенного диапазона запроса: Ожидается правая круглая скобка рядом с 0

Ах3 MSSQL2008 вроде

[ZVV]

Понимаете ли, обычно это занимает много времени, сочинять самому похожие примеры (которые всё равно будут не такие), тем более на какой-то загадочной таблице "RPDocument", которой у меня например нет..
Поэтому я и говорю, чтоб вы привели весь код, который не работает. Лучше всего если это будет тестовый пример на общеизвестных таблицах. Пока будете его делать, сорее всего и с проблемой разберётесь.

Ваш пример очень неполный, является частью какой-то другой квери. Бросается в глаза то, что "ERG_RPDocument_1" <> "ERG_RPDocument", а также отсутствие какого-бы то ни было "0"-ля в запросе, рядом с которым "Ожидается правая круглая скобка"... Именно поэтому и важен целостный пример в таких случаях.

PS
А вообще, зачем вам в дамнном случае эти дополнительные скобки, если не секрет?
Этот случай наиболее правильно сделать 2-мя отдельными нормальными рэнждами, без всяких таких "извратов"...

[gl00mie]

Цитата:

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

Таблица RPDocument, поля: Field1 (NoYesId), Field2 (EmplId)
при:

range.value(strFmt('%1.Field1==%2&&(%1.Field2=="")', qbdsJoin.name(), NoYes::Yes));

Всё работает

Какой запрос формируется у вас в этом случае? Точно ли он работает так, как вы предполагаете? Вообще, при формировании запросов лучше использовать методы из SysQuery, вроде queryValue() и SysQuery::valueEmptyString()

Цитата:

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

при добавлении скобок

'((%1.SelectedDivergence==%2)&&(%1.SelectedSupeVisor==""))'

Уже не работает, выдаёт:
SELECT * FROM ERG_RPDocument WHERE SalesPickingListJournalTable.PickingListId = ERG_RPDocument.PickingListId AND ((((ERG_RPDocument_1.SelectedDivergence==Да)&&(ERG_RPDocument_1.SelectedSupeVisor==""))))
Ошибка расширенного диапазона запроса: Ожидается правая круглая скобка рядом с 0

Ну правильно, у вас сформированное значение range не распарсилось и ушло на SQL в исходном виде. SQL использует мнемонические обозначение логических операций вместо && || и одиночный знак равенства вместо двойного... На всякий случай, посмотрите внимательно раздел axaptapedia на эту тему. Кроме того, обратите внимание, что в автоматически сформированной части запроса у вас таблица называется ERG_RPDocument, а в сформированном Range - ERG_RPDocument_1, это как-то странно...

Цитата:

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

Ах3 MSSQL2008 вроде

- тук-тук!
- кто там?
- да ведь это же я!
- кто "я"? "я" бывают разные!(с) м/ф про Винни-Пуха
Так вот, AX3 тоже бывают разные какая именно у вас версия ядра?

[ZVV]

Цитата:

... и ушло на SQL в исходном виде...

ну на SQL то оно ещё не ушло, иначе насколько я понимаю, была бы другая ошибка совсем. Здесб проблема остаётся ещё на стороне Аксапты, вероятно как раз в момент парсинга этого "расширенного диапазона запроса"..
Ну мне так кажется...

[DSPIC]

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));
    }
}

[Dronas]

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

[DSPIC]

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

[Dronas]

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

[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 В привеленном примере я поменял код номенклатуры и включил литералы в запросе.

[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...

[DSPIC]

Имелась ввиду не эта строчка. Строка с info(...) это только индикотор срабатывания запроса.
Я имел ввиду строку:
1. Orig:
rangeValue = strFmt("((ItemId==\"%1\") && (PurchModel==%2))", "B-R12", enum2int(NoYes::Yes));
2. После

Цитата:

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

должно быть что-то вроде:
rangeValue = strFmt("((ItemId==\"%1\") && (PurchModel==\"%2\"))", "B-R12", NoYes::Yes);
(убрали enum2int(..), поменяли формат)
Согласен, что сис-ма по-хорошему должна проглотить, однако такой range не срабатывает (т.е. запрос ничего не возвращает),
в чем и была причина неработоспособности запроса у Dronas.

[Dronas]

Цитата:

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

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

Оно NoYesId

[AndyD]

Цитата:

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

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

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

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

[gl00mie]

Цитата:

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

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

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