Ну, кроме внешних источников данных, ибо не 8.2.
т.е. есть ADODB.recordset где-то 3мегазаписей, надо быстро запихать в ТЗ, чтобы крутануть в отчете СКДшном потом.
Хранить в базе тоже не предлагать, ибо обновления данных во внешнем источнике весьма странные могут быть. Интересуют именно "грязные" хаки по получению ТЗ.

90% времени приходится на заполнение строк ТЗ поколоночно :(

GameWithFire?

ЗЫ. Сам не пробовал

перейти на 8.2

отдельную базу сделать под этот отчет на 8.2

(2) хм... счас попробую
(3) ага, вот прям взяли и перешли за несколько часов все

А внешний источник данных использовать не пробовали?

Упс. Сорри

Лучший хак - вместо * выбирать конкретные поля.

(8) запрос в скуле выполняется 18-20 секунд, перекачка в ТЗ 1с - десять минут

(5) Проверишь - не забудб результаты теста показать...

(9) Однако. 3 миллиона записей и сколько полей? Любопытно стало )

(11) пока 7

(12) А в какой части заполнения ТЗ наибольшая задержка?
Например "Таблица.Добавить()" или "Fields(Сч).Value" или что-то ещё. Не анализировал?

Сделай, например, регистр сведений и скулем копируй из скулевской таблицы напрямую в скулескую таблицу РС

(0) почему в базе хранить не хочешь?

(13) по сумме примерно так:    
75% ТМП = Recordset.Fields(Поле).Value;
25% Стр[Поле] = ТМП;

(15) механизм синхронизации, обновление базы и т.п. ради одного отчета

(16)+ на ТЗ.Добавить столько же, сколько на 7 штук Стр[Поле] = ТМП;

(17) какой механизм? сразу всю таблицу заливай, а если хочется "грязного" пиши данные сразу в скуль

(0) Могу подсказать "грязный хак":
Делаем регистр сведений в конфигурации.
После создания таблицы в SQL заменяем её на вьюху с таким же именем с твоим запросом.

короче, на части данных (скопируйте в эксельку, кому непонятны колонки):
Записей    1000    10000    20000    30000    40000    50000
1с    0,65    6,6    13,38    20,14    27,26    35,78
ЕИ    0,13    1,38    2,74    4,25    5,16    6,98
Отношение    5    4,782608696    4,883211679    4,738823529    5,282945736    5,126074499

вот миста, похерила табуляции....

(20)
как решаете проблему удаления таблиц при реструктуризации?

(23) Так если не менять этот регистр, не загружать - выгружать из dt, то он не реструктуризируется.
В случае изменения, вернуть таблицу, пересоздать вьюху заново заготовленым скриптом.
Вообще это запрещенный "грязный хак", но зато работает очень быстро.

(0) ВК GameWithFare, ComSafeArray

попробовал мой совет? Результаты есть?

(26) -> (21)

(27) расшифруй

(28) в (21) сравнение заполнения ТЗ из ADODB.Recordset средствами 1с (заполнение реквизитов Строк ТЗ в цикле) и средствами Enterprise Integretor (gamewithfire.dll) на разном количестве строк на моем компьютере. всего 7 колонок в таблице (если влом читать всю ветку).

Recordset.Fields(Поле).Value - тут надо Recordset.Fields(Поле) в массив или в структуру перед циклом вытащить. Сразу поди раза в 2 раза и ускорится.

Есть способы ускорить без ВК: асинхронный фетч, запихивать в рекордсет структуру в виде "ЗначениеВСтрокуВнутр" и т.п.

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

рекордсет весь целиком в комсэйвэррэй можно, но он падает по нехватке памяти

(31)

Поле1ЧтобыПолучать = Recordset.Fields(Поле1);
Поле2ЧтобыПолучать = Recordset.Fields(Поле2);

Пока ... Цикл

....
   Поле1Значение = Поле1ЧтобыПолучать.Value;
   Поле2Значение = Поле2ЧтобыПолучать.Value;
....

КонецЦикла;

(33) т.е. так не только первая строка получается?

(34) На получение Com-объекта "Field" выражением Recordset.Fields(Поле) тратится до фига времени. И для выражения Recordset.Fields(Поле).Value это делается в каджой строчке на каждое поле, а можно схитрить и эти объекты Field получить заранее. Смущаеть, наверное, что кажется что эти поля "конкретной строки"? Нет, это поля рекордсета, а Поле.Value - значение в текущей строке.