v7: Зависает отчет (оперучет, SQL, 1с++) #653341

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

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

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

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

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

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

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

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

Отчет рисовала я :). Вот строчка кода, на которой валится отчет:    КонецЕсли;   Переменная СоедГород в данном случае равна 1.

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

Лучше покажи, после этого Сообщить(Текст);

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

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

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

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

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

В курсе. :)

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

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

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

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

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

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

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

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

В общем так. Базы нет под рукой, и не могу воспроизвести текст запроса на рабочей базе с нужными фильтрами :(. В целом - что-то подобное: СпрТов.SP3500 [Производитель $Справочник.Производитель], SUM(Kol1) Kol1, SUM(Seb1) Seb1, SUM(ST1) ST1,   GROUPING (СпрТов.SP3500) as Группа1 FROM               (SELECT SP6886, SP6888, 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

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

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

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

Попробую.

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

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

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

Смущает вот эти ступенчатые инеры INNER JOIN SC46 СпрКл ON MainTab2.SP6888 = СпрКл.ID INNER JOIN SC5677 СпрГор ON СпрКл.SP5699 = СпрГор.ID Помнится у меня что-то подобное тормознее было, чем left с условием IS NOT NULL.

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

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

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

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

Полной уверенности нет, но есть подозрение, что это не выполняется вообще никогда. Т.е. задумка была, но не реализована. Т.к. выше встречается вот такой код:

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

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

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

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