Статья вряд ли заинтересует правоверных джедаев, но может пригодится для олдфагов вроде меня, использующих тёмную силу "загугли" и "копипаста".
Итак, при входе на определенную форму с динамическим списком получаем ошибку:
Microsoft SQL Cannot create a row of size 8077 which is greater than the allowatte maximum row size of 8066
Типа, длина записи в таблице MS SQL не может превышать размера страницы - 8 кб.
Ошибки нет в PosgreSQL, где варится тестовая база. Но переход рабочей базы на PSQL не рассматривается по религиозным причинам. Ошибка произвольно появлялась то у одного, то у другого пользователя и далее уходить не собиралась. Трассировка ничего не дала, а в консоли запросов ошибки не было. В консоли запросов у конкретного пользователя с ошибкой даже и результата не было, только пустые колонки, но ошибка при открытии формы - была.
По советам трудящихся "возвертай всё взад, <падший ангел апокалипсиса>" вернул исходный запрос и с удивлением обнаружил, что лучше не стало. Истерически паникуя с воплями "Шеф, шеф, всё пропало!", обращаемся к вселенскому разуму.
Запрос просто не может генерировать Армагеддон.
Помощь бывалого админа сервера 1С была неоценимой: "Запрос слишком большой, превышающий максимальный запрос для SQL. В 1С есть трассировка <а мужики то и не знали>. Надо исправить запрос." Спасибо, Кэп! Другой правоверный прогер сказал, что что-то такое было и после исправления дюжины ошибок в монструозном запросе, полегчало, но у меня не тот случай.
В интернете про эту проблему ничишуя толком не нашел. Походу в гугле забанили, ибо обнаружил только какие-то мантры сенсеев про то что, запрос, написанный нами, и отправленный от 1С к серверу отличается нюансами (см. анекдот про Василия Ивановича, Петьку и нюанс). Они явно о чём-то знали. Но путь ситха джедая усеян горами трупов из ошибок и обработок.
На infostart, на форумах 1С, на форумах Axapta сенсеи говорят одно и то же: резать запрос.
В ходе долгих поисков по тырнету в очередной раз прочитал очевидное от сенсеев: 1С под капотом подрубает к запросу всякуюкуну внутренние запросы, например, сортировки на форме.
Содержимое запроса, вызывающее взрыв радиатора SQL под капотом 1С.
Звонок юзеру про сортировку - активно юзает. Бинго. В 1С Предприятие удаляем настройки формы - по-ба-ба-м... ошибка исчезает... На всякий случай, в 1С:УТ11 это делается через 1С Предприятие в панели "НСИ и Администрирование", далее "Настройки пользователей и прав", "Персональные настройки пользователей", "Настройки пользователей". У нужного пользователя я жамкнул "Очистить всё" и позже пожалел, потому что удалились настройки очень важных отчетов, а что там было, никто не помнит. Поэтому надо выбирать конкретную форму и нажимать "Очистить".
Магия 1С
Ошибки нет! Но ненадолго... Стоит отсортировать по колонке - 1С даёт пинка под зад. Но мы на верном пути - печень не обманет. Она нутром чует.
Но запрос крохотный как мои достижения, в то время как ошибка вылезает явно из-за огромного как мои амбиции select-a. Стопудовые запросы в тридцатью таблицами почему-то не вылетают, как фанера над Парижем, а крохотный запрос вызывает эффект Челябинского метеорита.
Значит, что-то кроме сортировки в форме добавляет адынэс. Смотрим на используемые реквизиты, которые вытягиваются запросом. И тут находим золотую жилу с типом:
ДокументСсылка.
Но судя по соцопросам, используется всего пара документов. Меняем реквизит ДокументСсылка на ДокументСсылка.НашСамыйГлавныйДокумент, а СправочникСсылка удаляем вообще совсем нафиг навсегда. Ошибка исчезает.
Бонусом идёт ускорение запроса и мгновенное ускорение открытия формы. Профит. С ноги открываем дверь в чат корешей, требуем пива и королевских почестей.
"А почему вообще вдруг возникла ошибка?" - вопросит внимательный читатель: "Ведь до какого-то момента всё летало нормально." Всё верно, просто новые справочники и документы растут как грибы-мутанты после кислотного дождя. И случилось неочевидное - после добавления нового мелкого справочника MS SQL подняла бунд.
