Собственно, проблема такая.
Есть отчет, переписанный на SQL через 1с++.
Через какое-то время (только в этом отчете) обнаружилась одна проблема.
Описываю: когда указываешь дополнительную группировку и нажимаешь "сформировать", отчет формируется без проблем. Но если еще раз нажать "сформировать", 1с зависает, помогают только 3 кнопки.
Наличие этой группировки добавляет еще одно внутреннее соединение в запрос.
Т.е. пример: у нас есть реквизит Город типа Справочник, у этого города есть реквизит Регион типа справочник Регионы, вот только если выбрать дополнительно регион, проявляется проблема. При этом в запросе появляется строчка кода, добавляющая соединение справочника Города со справочником Регионы.
Отладка показала следующую вещь. Сам запрос выполняется сколько угодно раз, и результаты запроса без проблем выгружаются в ТЗ.
Но: если выполнять запрос больше одного раза, после собственно выполнения запроса, отчет зависает практически на любой строчке кода в 1с.
К примеру, отчет может подвесить строчка Таб = СоздатьОбъект("Таблица").
Может проблема известная и уже знает как с ней бороться.
Ах да, конфа нетиповая, 27 релиз, SQL 2000.

А остальное самим нужно додумать?

где-то неправильно. Такой ответ пойдеть )))

(1) Наводящие вопросы принимаются :).

Скорее всего текст запроса формируется динамически, и при повторном запуске неправильно формируется тест.
Или со временными таблицами.
Ну так, потелепатировать.

(3) Наводящий вопрос: сколько вы не доплатили человеку, который рисовал этот отчёт? :-))

(3) Можно текст запроса вывалить, надеюсь он не на три страницы.

все просто: не объявляются локальные переменные.
при совпадении имени переменной например текста запроса
может получиться мегазапрос.

Отчет рисовала я :).
Вот строчка кода, на которой валится отчет:
   Если СоедГород = 1 Тогда  
       //если фильтр идет по группе, берем внутреннее соединение, иначе левое
       Текст = Текст + ?(ВыбРегион.Выбран() = 1,"INNER","LEFT") +" JOIN SC5677 СпрГор ON СпрКл.SP5699 = СпрГор.ID
       |";
   КонецЕсли;  
Переменная СоедГород в данном случае равна 1.

(7) ну это так потелипатировать )))

Лучше покажи, после этого

Сообщить(Текст);

При повторном формировании отчета делаю Сообщить("Текст").
Текст запроса остается преждним.
ТЗ с данными, которая выдается на экран после выполнения запроса, вроде как тоже похожа на правильную. Но построчного сравнения не делала.
Базы, к сожалению, нет под рукой. Могу глянуть чуть позже.
Вопрос поступил от пользователя. Отчет под рукой есть.

(9) Мне, к сожалению, самой приходится телепатировать. :)
Пока известно, что отчет валится после дополнительного соединения.

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

(8) Вы про мегапарсер вообще в курсе?

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

(14) В курсе. :)

(1) Попробуй простой текст запроса выполни дважды.

(8)
если запрос к ms sql, то хорошо явно указывать подсказки блокировок.

т.к. возможно блокировки при первом выполненни
блокируют выполнение при повторном.

(0) прибить cfg  и mlg , для начала

да, и хинты нолок в текст запроса

(0) обновление статистик обычно помогает. оптимзатору иногда крышу сносить при усложнении запросов, если статистка старая. ну или (18), но это уже сложнее. обычно помогает более простой способ. мне уже не раз помогало = в том числе при больших объемах данных.

ой. как обычно не дочитал до конца :). чтобы зависал после определ. кол-ва выполнений, это не статистика. тем более на произвольной строчке кода = это вообще хрень какая-то.

(22) "это вообще хрень какая-то."

хорошо подитожил)

Тебеж попросили.
Ответь на (10)

В общем так. Базы нет под рукой, и не могу воспроизвести текст запроса на рабочей базе с нужными фильтрами :(.
В целом - что-то подобное:

SELECT  
СпрТов.SP3500 [Производитель $Справочник.Производитель], SUM(Kol1) Kol1, SUM(Seb1) Seb1, SUM(ST1) ST1,  
GROUPING (СпрТов.SP3500) as Группа1 FROM              
(SELECT SP6886, SP6888,
SUM(Kol1) Kol1, SUM(Seb1) Seb1, SUM(ST1) ST1
FROM
(SELECT SP6886, SP6888,
CASE WHEN DATE_TIME_IDDOC BETWEEN :НачДата1 AND :КонДата1~ THEN SP6889 ELSE 0 END Kol1,
CASE WHEN DATE_TIME_IDDOC BETWEEN :НачДата1 AND :КонДата1~ THEN SP6890 ELSE 0 END ST1,
CASE WHEN DATE_TIME_IDDOC BETWEEN :НачДата1 AND :КонДата1~ THEN SP6891 ELSE 0 END Seb1,
IDDOC
FROM $Регистр.УчетПродажОб AS РегПрод
WHERE (РегПрод.DATE_TIME_IDDOC BETWEEN :НачДата AND :КонДата~)) AS MainTab
GROUP BY SP6886, SP6888) AS MainTab2
INNER JOIN SC33 СпрТов ON MainTab2.SP6886 = СпрТов.ID
INNER JOIN SC46 СпрКл ON MainTab2.SP6888 = СпрКл.ID
INNER JOIN SC5677 СпрГор ON СпрКл.SP5699 = СпрГор.ID
WHERE (СпрКл.SP5699  = :ВыбГород) AND (СпрГор.SP5708  = :ВыбРегион) GROUP BY СпрТов.SP3500 WITH ROLLUP

Глюк происходит, когда в запросе присутствует эта строчка:
INNER JOIN SC5677 СпрГор ON СпрКл.SP5699 = СпрГор.ID

(25) хинты (nolock) понавтыкай , для начала

(25) у вас што, про метапарсер не слышали?

(27) Запросу сто лет и писался на чистом скуле (когда практически вообще его не знала :)), ну а сейчас переделывать все на метапарсер желания нет :).

(26) Попробую.

SP5699 какой тип имеет ? в справочнике ?

это реквизит какого типа ?

ЗЫ: <справочник>, без вида поди, да ?

Смущает вот эти ступенчатые инеры

INNER JOIN SC46 СпрКл ON MainTab2.SP6888 = СпрКл.ID
INNER JOIN SC5677 СпрГор ON СпрКл.SP5699 = СпрГор.ID

Помнится у меня что-то подобное тормознее было, чем left с условием IS NOT NULL.

SP5699 - реквизит справочника Контрагенты. Называется Город. Тип - Справочник.Города.

А если по этому условию попадает Left как работает запрос ?

   Если СоедГород = 1 Тогда  
       //если фильтр идет по группе, берем внутреннее соединение, иначе левое

       Текст = Текст + ?(ВыбРегион.Выбран() = 1,"INNER","LEFT") +" JOIN SC5677 СпрГор ON СпрКл.SP5699 = СпрГор.ID
       |";
   КонецЕсли;

Если что, база объемом где-то 5 гиг, т.е. небольшая.

Поставьте признак Сортировка (36) на реквизит Город в справочнике Контрагенты (создайте индекс)

(35) Полной уверенности нет, но есть подозрение, что это не выполняется вообще никогда. Т.е. задумка была, но не реализована.
Т.к. выше встречается вот такой код:
   Если ВыбРегион.Выбран() = 1 Тогда
       СоедКл = 1;
       СоедГород = 1;
   КонецЕсли;

Все ответы, которые прямо сейчас попробовать возможности нет, обязательно приму к сведению!

(28) так если заменить названия на человечьи - скорее всего, и ошибку проще увидеть будет

(40) Я бы не сказала, т.к. уже день ковыряю отчет с нормальными "человеческими" именами :).

(40) Непоможет. Не в данном случае.
(0) Или текст в студию, или лучше сохранить отчет как внешний и положить на файлопомойку. Ну так проще будет, а то угадайка неработает я так понял.