|
17.04.2012, 15:29 | #1 |
Роман Долгополов (RDOL)
|
Преобразование query в строку sql
знает ли кто нибудь способ получить по квери его представление в виде sql строки пригодной для непосредственного выполнения сервером БД или какое нибудь готовое решение для корректного преобразования значений range в условия на Т-SQL/PL-SQL?
требуется дать пользователю возможность задать произвольные ренжи на квери, а потом получив запрос использовать его в качестве основы для выполнения другого гораздо более сложного запроса с синтаксисом который невозможно получить стандартными средствами dax просьба не сводить обсуждения к вопросам зачем/это неправильно/сделайте стандартно и т.д., а обсуждать конкретно эту техническую задачу нужно это для существенного ускорения некой операции. возможность отрубания стандартной функциональности расширенного фильтра для упрощения формирования условия where так же здесь не обсуждается - с таким упрощением проблема перестает быть проблемой. использовать трассировку для выковыривания текста запроса то же не вариант. qbds.toString() вариант, но его надо допиливать - СУБД такое не съест DAX 2009 SP1 EE RU8 |
|
17.04.2012, 16:40 | #2 |
Axapta Retail User
|
|
|
|
За это сообщение автора поблагодарили: mazzy (2), db (2). |
18.04.2012, 08:17 | #3 |
Участник
|
В общем случае Query может содержать несколько последовательных запросов. Не связанных друг с другом и не подчинённых друг к другу. Т.е. просто независимые друг от друга запросы разной структуры, которые queryRun обрабатывает последовательно.
Даже если брать за основу не весь Query, а QueryBuildDataSource, то и тут есть нюансы. Например, я себе не представляю, как можно реализовать одним SQL запросом QueryBuildDataSource, содержащий QueryFetchMode::One2Many. Понятно что все эти "экзотические" возможности недоступны для пользователя через функциональность расширенного фильтра. Но ведь для системы нет никакой разницы - Query полученный от пользователя и Query созданный программно это одна и таже сущность. Поэтому я сомневаюсь в том что в системе есть какой-то стандартный инструмент, который сможет превратить в чесный SQL-текст любой Query/QueryBuildDataSource. Всё-таки наличие у аксаптовского Query таких "экзотических" возможностей, делает его гораздо более сложным объектом, нежели просто SQL-запрос. Если говорить даже просто о преобразовании значения range, в некоторое логическое условие, то и тут не вижу никакаих надежд на наличие стандартных инструментов . Стандартный метод Global::inRange() реализуется через запрос к временной таблице. Если бы существовал транслятор, доступный из X++, стали бы они так делать? Хотя... всё может быть Также не исключаю возможность существования самописных трансляторов. Но они ли вам нужны? |
|
|
За это сообщение автора поблагодарили: db (2). |
18.04.2012, 13:30 | #4 |
Роман Долгополов (RDOL)
|
Цитата:
Сообщение от S.Kuskov
В общем случае Query может содержать несколько последовательных запросов
..... Понятно что все эти "экзотические" возможности недоступны для пользователя через функциональность расширенного фильтра ..... Хотя... всё может быть Также не исключаю возможность существования самописных трансляторов. Но они ли вам нужны? Ну про стандартные я даже и не мечтаю - так что если кто поможет ссылкой на самодельное подобное извращение то буду вполне доволен Пока склоняюсь к разбору и переформатированию результатов qbds.toString(). Ну и тут своя бяка нашлась - на некоторых (вполне нормально исполняющихся, но достаточно сложных по структуре) запросах выполнение этого кода валит аксапту ... |
|
18.04.2012, 15:48 | #5 |
----------------
|
Решения нет, но есть вот такая мысль.
1. Создать компанию "ttt" без данных 2. Нужный запрос выполнить в рамках этой компании. Обязательно без параметризации. 3. Со стороны SQL отловить такой запрос (к компании ttt) и сохранить в какую-нибудь табличку 4. Использовать полученный запрос из таблички. п.3 кажется реализуемым, вот только не знаю как |
|
25.04.2012, 18:37 | #6 |
Роман Долгополов (RDOL)
|
всем спасибо за идеи.
сделал всё таки через отлов трассировки в таблицу по мотивам Получить Transact-SQL из QueryRun естественно с forceLiterals=true с левыми компаниями связываться не стал. перед трассируемым исполнением на первый датасорс запроса накладываю условие RecId==0, которое потом легко найти и вырезать в готовом sql-тексте |
|
|
За это сообщение автора поблагодарили: mazzy (2), S.Kuskov (1). |
25.04.2012, 22:11 | #7 |
Участник
|
Если решили завязаться на трассировку, то я бы предложил дописать свой код в Application.SysTrace(), где и перехватывать созданные запросы.
Для передачи результата в прикладной код можно воспользоваться GlobalCache() на Application. Можно так же не допускать записи в лог, введя флаг перехвата через тот же GlobalCache().
__________________
Axapta v.3.0 sp5 kr2 |
|
25.04.2012, 22:52 | #8 |
Участник
|
Андрей, а так rls ловится? То, что не ловятся подсказки оптимизатора самого скуля, понятно...
|
|
26.04.2012, 00:12 | #9 |
Участник
|
Не понял вопрос
В лог пишется запрос в том виде, как он уходит на сиквел, в том числе с ограничениями rls и всеми хинтами, которые были добалены
__________________
Axapta v.3.0 sp5 kr2 |
|
12.05.2012, 13:22 | #10 |
Участник
|
В AX2012 появился метод getSQLStatement и директива generateonly
dax-lessons: Get underlying SQL query using getSQLStatement [Dynamics AX 2012] |
|
|
За это сообщение автора поблагодарили: iCloud (4). |
Теги |
query, t-sql, преобразование, расширенный фильтр |
|
|