> Время выполнения прямого запроса к базе на МССКЛ сервере через квери аналайзер и АДО различается в десятки раз, причем эффект стабильнейший, и от загрузки сервера мало зависит.
> Запрос в квери аналайзере выполняется за 2 секунды, а через АДО - застывает, и через 2-3 минуты вываливается сообщение TimeOut Expired.
> В течение всей осени такого не было, эти скорости практически не различались.
> Другой запрос через АДО в этой же обработке выполняется нормально в обоих случаях.
В чем может быть причина?

(0)Код в студию! Текст запроса и код в котором ты дергаешь его с помощью АДО, текст строки подключения тож (кстати версию АДО тож неплохо бы узнать).

Наверное база выросла.
Установи CommandTimeout например

(1)Щас код запроса представлю, код обработки весь сюда закинуть невозможно (800 строк), представлю избранные места. Добавлю, что на серваке, где это происходит, не только эти глюки, идут какие-то непонятные блокировки таблиц, вызываемые самописными программами, написанными на делфях, наши программеры сейчас с этим разбираются.
Но, повторюсь, запрос в квери аналайзере несмотря на это работает.

(2)CommandTimeout установлен, но причем здесь это, в квери аналайзере запрос выполняется в д_е_с_я_т_к_и раз быстрее, чем через АДО
(1)Код запроса:
SELECT 'tovar' AS vidtov , 0 AS kodtov ,
vi.id_vendor, vig.nds,
CAST(SUM(vig.cen_buy * vig.kol_vo) AS FLOAT) AS summ,
CAST(SUM(vig.kol_vo) AS FLOAT) AS kol_vo
  FROM vendor_income vi
  INNER JOIN vendor_income_goods vig
    ON vi.id = vig.id_income
  INNER JOIN spr_goods sg
    ON vig.kod_goods = sg.id_kod
  INNER JOIN kateg kt
    ON sg.id_kateg = kt.id
  LEFT JOIN vendor_info_public vip
    ON vi.id_vendor = vip.id_vendor
  WHERE (vi.date_prih BETWEEN '20051001 00:00:00.000' AND '20051001 23:59:59.998')
    AND vi.delete_marker=0 AND vi.draft=0
    AND vi.id_vendor NOT IN (1389, 13505, 17665, 35841, 73344, 85696, 127360, 127424, 127680, 131136, 135680, 137792, 148672, 154176, 154944, 158130, 158237, 158285, 158337, 158367, 158383, 158399, 158400, 158403, 158405, 158415, 158418, 158429, 158430, 158434, 158436, 158437, 158445, 158449, 158458, 158463, 158464, 158474, 158535, 158555, 158588, 158590, 158602, 158667, 158690, 158700, 158706, 158735, 158736, 158741, 158757, 158777, 158788, 158810, 158848, 158963, 159090, 159105, 159156, 159199, 159428, 159481, 159482, 159532, 159546, 159608, 159680, 159737, 159747, 159772, 159901, 159913, 159919, 159951, 159985, 160010, 160032, 160058, 160123, 160212, 160227, 160254, 160261, 160282, 160378, 160428, 160545, 160596, 160677, 160727, 160790, 160854, 160864, 160866, 160868, 160869, 160870, 160873, 160878)
    AND kt.nom <> 31
    AND sg.id_kod NOT IN(552020, 552029, 599931, 599932, 599933, 599940)
GROUP BY vi.id_vendor, vig.nds
UNION
SELECT 'paket' AS vidtov , sg.kod AS kodtov ,
vi.id_vendor, vig.nds,
CAST(SUM(vig.cen_buy * vig.kol_vo) AS FLOAT) AS summ,
CAST(SUM(vig.kol_vo) AS FLOAT) AS kol_vo
  FROM vendor_income vi
  INNER JOIN vendor_income_goods vig
    ON vi.id = vig.id_income
  INNER JOIN spr_goods sg
    ON vig.kod_goods = sg.id_kod
  INNER JOIN kateg kt
    ON sg.id_kateg = kt.id
  LEFT JOIN vendor_info_public vip
    ON vi.id_vendor = vip.id_vendor
  WHERE (vi.date_prih BETWEEN '20051001 00:00:00.000' AND '20051001 23:59:59.998')
    AND vi.delete_marker=0 AND vi.draft=0
    AND vi.id_vendor NOT IN (1389, 13505, 17665, 35841, 73344, 85696, 127360, 127424, 127680, 131136, 135680, 137792, 148672, 154176, 154944, 158130, 158237, 158285, 158337, 158367, 158383, 158399, 158400, 158403, 158405, 158415, 158418, 158429, 158430, 158434, 158436, 158437, 158445, 158449, 158458, 158463, 158464, 158474, 158535, 158555, 158588, 158590, 158602, 158667, 158690, 158700, 158706, 158735, 158736, 158741, 158757, 158777, 158788, 158810, 158848, 158963, 159090, 159105, 159156, 159199, 159428, 159481, 159482, 159532, 159546, 159608, 159680, 159737, 159747, 159772, 159901, 159913, 159919, 159951, 159985, 160010, 160032, 160058, 160123, 160212, 160227, 160254, 160261, 160282, 160378, 160428, 160545, 160596, 160677, 160727, 160790, 160854, 160864, 160866, 160868, 160869, 160870, 160873, 160878)
    AND sg.kod IN(599931, 599932, 599933, 599940)
GROUP BY sg.kod, vi.id_vendor, vig.nds

<><>•ЬЁЧЄљЋЧИЦЇЖВС©ЧыЖШУПСщ”§д›з?Јјз«еКтд

К скорости выполнения это конечно не относиться, но запрос хоть вываливаться не будет

(6) Сейчас он равен 180. Есть обстоятельства, которые не позволяют делать его больше.
(1) Фрагменты из кода 1С:
//Установка соединения с сервером:
Процедура СвершитьКоннект(ConnectionString , conn , cmd)
  conn=createObject("ADODB.Connection");
  cmd=createObject("ADODB.Command");
  conn.ConnectionTimeOut=600; //время ожидания до соединения
  conn.CommandTimeOut=180; //время ожидания результата запроса
  conn.CursorLocation=3;
  try
    conn.Open(ConnectionString);
  except
    return;
  endTry;
  status("Activating connection...");
  cmd.activeConnection=conn;
  cmd.commandType=1; //T-SQL query
КонецПроцедуры //СвершитьКоннект()
//получение рекордсета:
Функция ПолучитьРС(ТекстЗапроса,КомандаАДО)
  КомандаАДО.commandText=ТекстЗапроса;
  rs=createObject("ADODB.RecordSet");
  status("Executing query...");
  rs=КомандаАДО.Execute;
  Возврат rs;
КонецФункции
//в одной из функций - вызов функции ПолучитьРС:
Возврат ПолучитьРС(queryText,cmdP);
(queryText - см. текст запроса выше)
//строка инициализации:
"driver={SQL Server}; server=myserver; user id=myid; pwd=mypwd; Database=mydb"