Отладка запросов 1С через SQL #576662

есть запрос. много запросов. виртуальные таблицы, вложенные, обычные... можно ли как то сварганить посмотреть связи всех таблиц в SQL которые соответственно получаются в запросе (с учетом последовательностей их вычисления конечно) ? хочет визуально как нибудь посмотреть на ЭТО...

ну ты захотел

для мс - профилер для постгри - сохранение в текст

+2 а, ступил кажется

Настрой технологический журнал

визуально, это называется план запроса. в 14 релизе кстати его можно как то через тех. журнал получать. не знаю как правда. не смотрел. по мне проще через профайлер.

ну так он (профилер) дает только "пермоментные" данные ) а мне надо чтоб подряд идущие таблицы виртуальные, а потом их обработка запросами, со слитием в одну единую таблицу, да еще чтоб связи все показал...

план запроса можно из скл получать. релиз тут какбе даже не причем...

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

"и грабить корованы"

делай пакет. план все покажет.

попробую. спс.

проблема только в том, что 1с может использовать пременные таблицы, которые она не удаляет, а очищает (транкейт) сответственно по текстам запросов нужно 1 раз заменять инсерты на селект инто, чтобы создать эти врем таблицы , а потом из 1с запроса транкейт.

спс

Инструмент называется Tracer.

оно, нет?

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

учитывая тошнотворные касты всего и вся, лутше получить 4 раделенных запроса чем одну мега кашу я все касты вычищаю

кстати, может план запроса из тех. журнала облегчит жизнь в этом плане. надо глянуть что там 1С понаделала.

У нас перехват на уровне сокетов MSSQL который меняет временные таблицы на постоянные с уникальными ИД в названиях.  Иначе, конечно ручками собирвать все запросы, парсить очень неудобно. Ну а если вопрос в теории ничего сложного нет - профайлер и все. Вся информация через него собирается.

журнал лутше вести в боевой базе для выявления ошибок или длителных запросов. НО в минимальном объёме тк ресурсоёмко. запись плана в рабочей бд будет слишком ресурсоёмкой операцией можно включить и забыть выключить, тоже и у тестовой для отладки лучше пользоваться средствами субд отлаживаться все равно нужно на отдельном процессе и план запроса лучше смотреть нескольких после первых итераций оптимизации если все ещё не устраивает производительность, тк процесс отимизации засасывающий - а 1с фаст рапид девелопмент.