QueryBuildRange.value() -->> SQL statement

[ni]

Есть ли способ конвертировать значение фильтров из запроса (QueryBuildRange.Value(ФИЛЬТР)) в условия для SQL запроса? Нарпример:

есть фильтр
.......addRange(fieldnum(InventTable, ItemId)).value("д..м");

а нужно получить, и потом как то выполнить....
........
select InventTable
where (InventTable.ItemId <= "м" && InventTable.ItemId >= "д")

[metal]

PHP-Code:

Query q = new Query();
querybuilddatasource qbds;
;
qbds = q.addDataSource(tablenum(ledgertrans));
qbds.addrange(fieldnum(ledgertrans,transdate)).value(sysquery::range(01\01\2003,systemdateget()));
box::info(qbds.toString()); 


Говорит
SELECT * FROM LedgerTrans WHERE ((TransDate>=01.01.2003 AND TransDate<=01.07.2003))

[ni]

Спасибо конечно, но что я теперь с этой строкой буду делать? как ее применить к While select например?

[Wamr]

А зачем???
Может что-то надо в задаче поменять?

[Garic]

PHP-Code:

    Common      table;
    QueryRun    queryRun;
    ;

    queryRun = new QueryRun(query);
    while (queryRun.next())
    {
        table = queryRun.getNo(1);
        info(table.(fieldNum(InventTable, ItemId)));
        ....
    } 


[ni]

Просто хотелось получиьь типовой подход к построению нестандартных отчетов, то есть появляется диалоговое окно в котором пользователь вводит критерии (по правилам Аксапты)например фильтрация по номенклатуре, датам, и т.п. а потом мне эти критерии хотелось бы использовать в SQL запросах в X++, потому что строить Query не всегда удобно. Вот и все задача, думал может есть какойто объект который сможет разложить стандартные критерии запросов на такие которые будут приемлимы в SQL.

[Wamr]

нет такого

[metal]

Если я не ошибаюсь, запросы на прямую к базе данных может выполнять метод executeQuery класса Statement. Его можно получить из класса ODBCconnection.
Результат такого запроса - класс ResultSet.

[Garic]

Zitat:

Изначально опубликовано ni
Просто хотелось получиьь типовой подход к построению нестандартных отчетов, то есть появляется диалоговое окно в котором пользователь вводит критерии (по правилам Аксапты)например фильтрация по номенклатуре, датам, и т.п. а потом мне эти критерии хотелось бы использовать в SQL запросах в X++, потому что строить Query не всегда удобно.

Это всего лишь дело привычки.

[Aethete]

SQL - стандарт ANSI\SPARK ...

а всякие извращения типа QueryBuildDataSource и т.д. - это самодятельность
только усложнающая жизнь...

если разработчики такие гении, чтож они не разработали собственную СУБД ...
в дополнение?

Все эти прибамбасы - для пыли в глаза ... все делается для усиления собственной значимости ...

[mazzy]

Почему не создали? Создали.
Попробуйте ключ native
Только native база не поддерживается уже давно.

Насчет QueryBuildDataSource (QBDS).
На самом деле я не думаю, что это извращение.
Если работать с текстовым запросом, то этот текстовый запрос постоянно парсить надо. А тут разработчику сразу предоставляется объект с методами.

Воспринимайте QBDS как обертку вокруг запроса. И жизнь сразу станет легче.

Насчет исходного вопроса ni.
Для этих целей в Аксапте уже есть инструменты.
Поглядите на форму и классы SysQueryForm.

[mazzy]

Маленькое добавление.
native база ОФИЦИАЛЬНО не поддерживается.
Т.е. нигде в рекламных материалах, документации вы этого не найдете. Официальная линия поддержки не отвечает на вопросы по этой базе данных.

[Aethete]

Простите, что напоминаю, но
Axapta реализована на
базе СУБД ORACLE и MS SQL ... как правило ..
и как следствие этого просто обязана пользоваться
средствами доступа к данным вышеупомянутых СУБД,
т.е. SQL, что порождает дополнительные затраты на вычесления
(все то же стандартное выполнение произвольного запроса, + предварительный
разбор на сервере приложений и формирование соответствующего SQL запроса...)
и перекачивание данных - с СУБД на сервер приложений - клиент и обратно ...
Причем перекачиваются все данные, относящиеся к базовому отношению
определенному в запросе, не важно нужны они, или нет, что естесственно
отрицательно сказывается на общем времени реакции системы ...
Чтобы в этом убедиться, можно просто открыть так называемый "паспорт записи".


То, что средства разработки Axapta предоставляют в качестве
классов и прочих дел - не более, чем надстройка представляющая
из себя более высокий уровень абстракции для конечного
пользователя (разработчика) ... и являющейся схемой метаданных
для работы интерпретатора (как я думаю и тому в подтверждение по крайней мере
две причины:
1. Формы, процедуры, запросы и т.д. разрабатываются средствами Axapta и
создаются непосредственно в Axapta - выполнение запросов на сервере приложений,
отображение на клиенте ...
2. Средства выполнения и отладки - это на мой взгляд - ключевой момент, т.к. любая ошибка
созданного модуля, запускаемого на уровне ОС может привести к краху этой самой ОС,
а возможность отладки - вообще недопустима, т.к. система на это время остановится, в то
время, как Axapta допускает возможность вызова системных функций ... правда я так
подозреваю - не всех... некий аналог пользовательских типов можно создать cредствами
container, но опять же ... представлены не все атомарные типы данных byte, word, dword ...
нет, функций для работы с указателями (не в интерпретации X++) и приведения типов данных ...
вобщем методов работы с памятью...
) ядра сервера приложений ...
И все эти самые средства разработки имеют одну, на мой взгляд основную
цель - скрыть от пользователя (разработчика) истинную логическую
модель данных в самой СУБД.
Кстати ... именно по этому (на мой взгляд) в схеме СУБД не определено
ни одного ограничения (кроме NOT NULL) ... вся логика зашита в слои
разработчика, к которому естесственно никто не пустит ... )

По поводу "программных слоев" - широко разрекламированное, якобы Know How
фирмы ...
На мой взгляд в этом нет ничего революционного ...
Любой программист, пишущий под любую ОС любую программу использует системные
вызовы ... чувствуете связь ...?
На всякий случай - объясню. Описывая создание на любом языке (Object Pascal [Delphi], C++, VB, Perl и т.д.)
например окошка (если например под винды..) компилятор все-равно запрашивает функцию
CreateWindow ...
а теперь запустите программу под 98 а потом под XP ... даю 101% гарантии, что окошки
будут разные по форме ... но функция то осталась та же ...
короче есть стандарт, называется API ... так вот это оно и есть ...

На самом деле Axapta не такая уж плохая система ... ничем не хуже остальных ... таких же...
Имеющая возможность доработки (правда с некоторыми оговорками...)

С наилучшими пожеланиями ...