есть запрос. много запросов. виртуальные таблицы, вложенные, обычные...

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

ну ты захотел

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

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

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

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

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

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

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

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

http://www.gilev.ru/1c/81/index/optimquery.htm

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

(11) попробую. спс.

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

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

(10) спс

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

(0) оно, нет?

http://infostart.ru/public/14692/

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

(17)
учитывая тошнотворные касты всего и вся,

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

я все касты вычищаю

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

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

(19)
журнал лутше вести в боевой базе для выявления ошибок
или длителных запросов.
НО в минимальном объёме тк ресурсоёмко.
запись плана в рабочей бд будет слишком ресурсоёмкой операцией

можно включить и забыть выключить, тоже и у тестовой


для отладки лучше пользоваться средствами субд

отлаживаться все равно нужно на отдельном процессе
и план запроса лучше смотреть нескольких после первых итераций

оптимизации если все ещё не устраивает производительность,

тк процесс отимизации засасывающий - а 1с фаст рапид девелопмент.