Доброго времени суток. Подскажите пожалуйста, почему при выполнении из 1С запроса встроенными средствами или через ADO запросы выполняются очень медленно или вообще вешают наглухо комп. А при выполнении того же запроса например через  IBExpert(база Firebird) все выполняется за несколько секунд. Заранее благодарю.

Кто сталкивался поделитесь опытом???

Берем обработку, в ней выводим время (в миллисекундах) отправки запроса, время завершения запроса, в профайлере sql смотрим время начала запроса, продолжительность, время окончания запроса.

Возвращаемся с результатами сюда.

(2) какую обработку??? Подскажеет??

(3) которую вы напишите. очевидно же.

ТекстЗапроса = "select d.nike, sum(s.schet)*(-1), d.cod_drv, c.ch_name, d.channel
|from drv_schet s, drivers d, channels c
|where s.cod_purpose in (2,3,12,21) and d.cod_drv=s.cod_drv and d.channel=c.channel and d.channel in (1,8,11)
|and s.d_mod between '"+Отчет.ДатаНачала+ "' and '" +Отчет.ДатаКонца+"' group by 1, 3, 4, 5 order by 4, 1";
НаборЗаписей = Новый COMОбъект("ADODB.RecordSet");
НаборЗаписей.ActiveConnection = Соединение;
НаборЗаписей.Open(ТекстЗапроса);

Запрос такого вида.... и как я узнаю в ней время??? Если при инициализации запроса обработка виснет наглухо, вместе с компом (

вы бухгалтер?

Вижу. Вижу. Вижу нехилый такой cross join.

82 000 000 записей в таблице....остальные мельче :)

(7) Неет....я уборщица %) Просто за ком пустили на 10 минут :)

Добавь inner join и возвращайся.

(9) Заметно.

(7)
для ORACLE и ms sql (>2000)

описание соединения в разделе условий - допустимо и эквивалентно inner join.

так что и FB  такое может быть.

(12) Согласен. Но я не вижу смысла рисковать.

(12)
я тоже предпочитаю правила  соединения описывать в join

До join  (выполнялось в IBExpert)

------ Информация о производительности ------
Время подготовки запроса = 16ms
Время выполнения запроса = 998ms
Среднее время на получение одной записи = 30,24 ms

После:

------ Информация о производительности ------
Время подготовки запроса = 19ms
Время выполнения запроса = 2s 871ms
Среднее время на получение одной записи = 114,84 ms

С inner join производительность упала.... :(

Тем более а если запрос будет описан средствами встроенного конструктора запростов? Производительность еще более упадет?

(0)
почти уверен, что  IBExpert
не считывает весь рекордсет.

а как ведет ВИД - не знаю.
в ADO - настраивается

(18) А можно ли из 1С не считывать весь рекордсет?? Ведь ИБЕксперт тоже стороннее приложение для базы как и 1С ...

Как настраивается? :)

+(18)
еще много зависит от драйвера.

помню. кому-то на этом форуме очень помогла смена драйвера FB

(20)
читайте документацию к RECORDSET.

(22) Это ты сейчас про тип курсора?

скорее всего IBExpert выбирает TOP сколько-то, а адо - все

(24) что-то вроде динамического списка

(23)
нет.
насколько я помню, по умолчанию (oledb или ado) выбирается
то ли 50 000 записей, то ли 50 мегабайт.

(26) что-то я не нашел такого в свойствах recordset-а

(27)
CacheSize

(28) На вскидку какое оптимальное значение? По умолчанию же 1??

(29)
на вскидку  - 30 000.

но вопрос из серии "сколько записей записывать в одной вложенной транзакции ".

однозначного ответа  нет.

Оук спасибо, следующая проблема.... вот:

ВЫБРАТЬ
    DRIVERS.NIKE,
    OP_STATUS_ARCH.D_STATUS КАК D_STATUS,
    OP_STATUS_ARCH.ORDER_ID КАК ORDER_ID,
    OP_STATUS_NAMES.STATUS_NAME,
    OPERATORS.FIO,
    CHANNELS.CH_NAME
ИЗ
    ВнешнийИсточникДанных.firebird.Таблица.CHANNELS КАК CHANNELS,
    ВнешнийИсточникДанных.firebird.Таблица.OPERATORS КАК OPERATORS,
    ВнешнийИсточникДанных.firebird.Таблица.OP_STATUS_ARCH КАК OP_STATUS_ARCH,
    ВнешнийИсточникДанных.firebird.Таблица.OP_STATUS_NAMES КАК OP_STATUS_NAMES,
    ВнешнийИсточникДанных.firebird.Таблица.DRIVERS КАК DRIVERS
ГДЕ
    OP_STATUS_ARCH.COD_OP = OPERATORS.COD_OP
    И OP_STATUS_ARCH.COD_DRV = DRIVERS.COD_DRV
    И OP_STATUS_ARCH.STATUS = OP_STATUS_NAMES.STATUS_ID
    И OP_STATUS_ARCH.D_STATUS > "03.02.2014"

УПОРЯДОЧИТЬ ПО
    D_STATUS,
    ORDER_ID

Виснет на мертво....на IBExperte 3-4 секунды, на 1С за 15 минут не выполнился :(( Как быть??

(31)
анализируйте
трассировки

которые можно настроить

в "Администратор источников данных ODBC"

(31) А зачем тебе перемножение таблиц OP_STATUS_ARCH и CHANNELS?

(31)
5 таблиц
и  3 соединения

так что

(7) был прав.

(33) где перемножение??

(34) блин...запрос висит в трассировку ОДБЦ ничего не пишется...

(35) Тебя кто учил писать запросы? Это вообще запрос двоечника.
Правильно пишет (34).

По какому условию связываются OP_STATUS_ARCH и CHANNELS?

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

блин...не связываются, но не суть я думаю, в channels  всего 17 строк

(39) не ...точно не проще....они меняются в секунду по паре раз ((

(40) Так она еще и с остальными таблицами начинает перемножаться в плане запроса. Скорее всего.

(42) Добавил условие....

Ждем результата.

(44) думает....

(44) Пустой результат...но быстрее ))