Проблема следущая. Существует запрос типа:

SELECT
    *
    INTO #VT
FROM
    ....
 

Этот запрос выполняется быстро. Но вот выборка из этой виртуальной таблицы #VT с одновременной типизацией значений полей

SELECT
    VirtTab.ИмяПоля [ИмяПоля $Справочник.ИмяСправочника],
    ...
FROM
    #VT VirtTab
 

а особенно если типизируемых полей несколько, то выполняется все это ОЧЕНЬ долго. Я слышал где-то что это из-за курсоров, через которые ODBCRecordSet или драйвер ODBC (непомню) работает с вирт. таблицами. Подскажите, кто знает как с этим бороться или отошлите на ветку где этот вопрос уже рассматривался, если таковая тема уже существует. Сам я поиском форума и глазами не нашел.

Примерно так же как и предыдущий, т.е. быстро. В этом то как раз и проблема, что именно с типизацией и именно из вирт. таблицы выборка осуществляется минуты три или больше. К примеру если мы напрямую сделаем запрос (без ВТ), т.е.:

SELECT
    А.ИмсяПоля [ИмяПоля $Справочник.ИмяСправочника],
    ...
FROM
    ... AS A
 

то выполняется это дело секунд за 5. Посему грешу на выборку с типизацией именно из вирт. таблицы.

Секунд 5-10 (примерно) все, кроме с типизацией выборки из ВТ. В случае с типизацией из ВТ время увеличивается до 3-5 минут. Все это время процесс скуля загружает процессор на 100%, пыхтит как сумасшедший. Я было подумал из-за памяти (ограничил скулю до 500Мб), но как показывает прямой запрос (не из ВТ) это не так, т.к. в этом случае запрос, как я уже говорил, с типизацией выполняется секунд 5-10.

Говорю же: при выборке напрямую запрос с типизацией работает быстро. А вот если мы результат нашего прямого запроса поместим в вирт. таблицу (как в буфер) и уже из нее еще одним запросом с типизацией попробуем вытащить данные, вот тогда скуль начинает дико выедать процессорное время и загружать систему непонятно почему. Поймите, что получаемые данные одинаковы, а вот затрачиваемое время ОЧЕНЬ разное. Объясните тогда в чем разница между выборкой из таблиц базы и выборкой из ВТ? Что такого начинает делать скуль что так вешает систему? На мой взгляд разницы не должно быть никакой, ибо и то и то таблицы.

(0) запрос без типизации работает быстро ?

Я не знаю как привести пример. Немогу же я всю базу здесь выложить? А чтобы реально загрузить скуль нуно много данных. Возьмите любую базу 1с (тестовую или рабочую) и в первом запросе (см. 1 пост) вместо ... подставьте, например, виртуальный регистр какой нибудь (у меня это РегистрОстатки) с какими нибудь измерениями и ресурсами, желательно по 3 каждого, а во втором запросе (где выборка из #VT) все измерения выбирайте с типизацией, ну и ресурсы просто для приличия выбирайте
На счет индексов: объясните по подробней что это и как создать мне их для ВТ? Просто никогда до селе не сталкивался с ними, небыло необходимости) Я нашел пример как создать индекс, но незнаю какой тип индекса нужен ODBCRecordSet для работы, как скуль поймет что таблица приндексирована? Как мне использовать имя созданного индекса моей ВТ?

И еще... я немного соврал ранее, без типизации полей работает также медленно. И еще я немного не договорил у меня к вт джойнится журнал 1с)) при чем джойнится корявенько, потому как без него се быстро выбирается из ВТ))) Простите меня дуру грешную))) Тему можно закрыть и удалить, желательно побыстрее, чтоб никто из знакомых не увидел моего позора

Я нашел в чем была трабла. Все тормоза были из-за ф-ции DATALENGTH которая использовалась у меня в связывании при обрезании одного из строковых полей по размеру другого строкового поля, по которым как раз таки ведется связывание. Я по простоте душевной думал, что скуль оптимизирует ее вызов. Оказалось что нет, скуль постоянно вызывал ее, что вызывало жутчайшие тормоза и время выполнения увеличивалось в разы.

p.s. обрезание делал обоснованно, так как IDDOC в регистре и IDDOC в журнале это не одно и то же. К IDDOC регистра добавляется еще и тип документа в 36-тиричной системе счисления. Хотя можно было конечно делать обратную операцию, т.е. не обрезать IDDOC регистра, а к IDDOC журнала прибавлять код базы. Но это так... размышления в слух... а вось кто столкнется с подобной проблемой.

Ну вобще-то я писал еще в 10-м посте (прочтите внимательно последний абзац), что джойню журнал, в 12-м просто решил более подробно объяснить ситуацию, на случай если кто с таким же столкнется и начнет грешить на ВТ. Почему я так уверенно грешил на ВТ? Потому как немного ранее я использовал DATALENGTH и ни чего не лагало, из-за чего у меня и в мыслях не возникло грешить на него и на оптимизатор запросов. Как оказалось зря. Теперь буду знать. И вообще все в том же 10-м посте я писал что тему можно закрыть.

P.S. Безошибочных людей небывает...