← На главную

Всем привет! Сегодня мы подробно рассмотрим проблему, с которой сталкиваются многие пользователи и администраторы 1С:Предприятия после обновления платформы до версии 8.3.23.1739. Речь идет о появлении «Неисправимой ошибки», которая сопровождается падением приложения и созданием дамп-файла при попытке запуска отчетов, особенно тех, что используют пользовательские варианты настроек.

Данная проблема проявляется при работе с отчетами, которые ссылаются на общую форму ОбщаяФорма.ФормаОтчета. Примечательно, что те же базы данных, но без пользовательских вариантов отчетов, функционируют без сбоев. Это указывает на то, что новая платформа 8.3.23.1739 может некорректно обрабатывать определенные элементы пользовательских настроек отчетов, что приводит к краху системы. Давайте разберем эту ситуацию по шагам и выясним возможные пути решения.

Разбираемся в сути проблемы и анализируем лог дампа

Проблема, как мы видим из первого сообщения, возникает после обновления платформы с 8.3.20.2184 до 8.3.23.1739. При запуске отчетов, имеющих пользовательские варианты, 1С падает с "Неисправимой ошибкой" и создает дамп. Важный нюанс: если пользовательских вариантов нет, ошибки тоже нет. Это является ключевой подсказкой.

Давайте посмотрим на фрагмент лога дампа, предоставленный автором, чтобы точнее определить место возникновения ошибки:

В логе мы видим:

1. Процесс rphost падает: process=rphost,OSThread=5508. Это говорит о том, что ошибка происходит на уровне серверного процесса, который обрабатывает запросы к базе данных.
2. Версия платформы, на которой произошел сбой: rphost_8.3.23.1739. Это подтверждает, что проблема связана именно с новой версией платформы.
3. Контекст ошибки: Context='Система.ПолучитьФорму : Отчет.ВедомостьПоТоварамНаСкладах.Форма ОбщаяФорма.ФормаОтчета.Форма : 223 : БыстрыеНастройкиЗаполнить; ОбщаяФорма.ФормаОтчета.Форма : 1566 : БыстрыеНастройкиСоздатьЭлементыУправленияИЗагрузитьЗначения; ОбщаяФорма.ФормаОтчета.Форма : 2605 : Элементы[ОписаниеРеквизита.ИмяКолонкиЗначение].ПутьКДанным = ИмяТаблицы + ".Значение";'. Этот фрагмент чрезвычайно важен. Он указывает на следующие моменты:
   • Ошибка происходит при попытке получить форму отчета, в данном случае Отчет.ВедомостьПоТоварамНаСкладах.Форма, которая использует ОбщаяФорма.ФормаОтчета.
   • Далее, мы видим ссылки на процедуры БыстрыеНастройкиЗаполнить и БыстрыеНастройкиСоздатьЭлементыУправленияИЗагрузитьЗначения. Это подтверждает нашу гипотезу о связи ошибки с пользовательскими «быстрыми настройками» отчетов.
   • Самое глубокое место в стеке вызовов указывает на присвоение значения свойству ПутьКДанным для элемента формы: Элементы[ОписаниеРеквизита.ИмяКолонкиЗначение].ПутьКДанным = ИмяТаблицы + ".Значение";. Это может означать, что платформа 8.3.23.1739 некорректно обрабатывает или интерпретирует путь к данным, сохраненный в пользовательских настройках, что приводит к критической ошибке и падению.

Таким образом, мы можем сделать вывод, что проблема кроется в механизме обработки пользовательских вариантов отчетов, в частности, быстрых настроек, когда платформа 8.3.23.1739 пытается инициализировать элементы формы и присвоить им путь к данным.

Какие шаги по диагностике мы уже предприняли

Прежде чем переходить к новым решениям, давайте вспомним, какие шаги по устранению проблемы уже были выполнены, как описано в первом сообщении:

1. Тестирование и исправление базы: Автор провел стандартную процедуру тестирования и исправления информационной базы. Этот шаг направлен на выявление и устранение логических и физических ошибок в структуре данных. Однако, в нашем случае, это не принесло результата, что может говорить о том, что проблема не в самой целостности данных, а в способе их интерпретации новой платформой.
2. Проверка через chdbfl.exe: Утилита chdbfl.exe (Check DB file) используется для проверки целостности файловой базы данных. Ее запуск не выявил ошибок, что еще раз подтверждает отсутствие физического повреждения файлов базы.
3. Перенос базы на другой сервер через выгрузку-загрузку: Этот метод позволяет исключить проблемы, связанные с конкретным оборудованием или конфигурацией сервера 1С. Поскольку проблема осталась, мы понимаем, что она не привязана к физическому серверу или файловой системе.
4. Проблема сохраняется как в файловом, так и в клиент-серверном варианте: Это важный момент, исключающий специфику файлового или клиент-серверного режима работы. Ошибка проявляется независимо от архитектуры развертывания, что еще раз указывает на глубокую проблему в самой платформе или ее взаимодействии с данными.
5. Тестирование на платформе 8.3.22.1923: Развертывание базы на тестовом сервере с платформой 8.3.22.1923 показало, что на этой версии платформы проблема отсутствует. Это является ключевым подтверждением того, что виновником является именно новая версия платформы 8.3.23.1739, а не сама база данных или ее конфигурация.

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

Решение 1: Откат платформы или использование стабильной версии

Учитывая, что на платформе 8.3.22.1923 отчеты работают без ошибок, наиболее очевидным и надежным решением является использование более стабильной версии платформы. Многие опытные пользователи и администраторы форума 1С также советуют этот подход.

Почему откат платформы?

Новые версии платформы 1С, особенно сразу после выхода, могут содержать ошибки или недоработки, которые проявляются на различных конфигурациях или специфических данных. Сообщение 12 на форуме подтверждает, что "видел на днях ошибку 23платформы что затирает пользовательские настройки отчета. Так что похоже в 23 несколько ошибок с настройками отчетов." Это говорит о том, что проблемы с настройками отчетов в 8.3.23.1739 не единичный случай, а скорее всего, баг платформы.

Автор темы изначально не рассматривал откат как желательный вариант из-за требований к обновлению конфигураций БГУ и ЗУП. Однако, как было уточнено в сообщении 11, для ЗУП (редакция 3, версия 3.1.27.23) минимальная требуемая версия платформы — 8.3.22.1923, а не 8.3.23.1739. Это означает, что переход на 8.3.22.1923 вполне допустим для работы с обновленными конфигурациями и является более безопасным выбором.

Подход автора: Запуск агента сервера от другой платформы

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

1. Установка стабильной платформы: На сервер, где уже была установлена 8.3.23.1739, устанавливается дополнительная версия платформы 1С, например, 8.3.22.1923. При установке 1С позволяет иметь несколько версий платформы одновременно. Каждая версия платформы устанавливается в свою директорию (например, C:\Program Files\1cv8\8.3.22.1923\bin и C:\Program Files\1cv8\8.3.23.1739\bin).
2. Запуск дополнительного агента сервера: Каждая установленная платформа может запускать свой собственный процесс агента сервера (rphost). Обычно при установке платформы запускается один агент сервера, связанный с этой версией. Чтобы запустить агент от другой версии, можно либо настроить службу сервера 1С:Предприятия через оснастку "Службы" (Windows Services), либо запустить его вручную с помощью командной строки, указав путь к исполняемому файлу нужной версии платформы.
   • Если у вас кластер серверов 1С, вы можете создать новый рабочий сервер (rphost) в этом кластере и указать для него путь к исполняемым файлам более старой платформы (например, 8.3.22.1923).
   • Либо вы можете создать отдельный кластер серверов 1С, который будет работать на другой версии платформы.
3. Привязка базы к нужному агенту сервера: Самое главное – это направить проблемную базу данных (в данном случае, УТ 11.1.4.34 с пользовательскими настройками отчетов) к тому агенту сервера, который работает на стабильной версии платформы (например, 8.3.22.1923).
   • В консоли администрирования кластера серверов 1С, для вашей проблемной базы данных, вы можете указать, на каком рабочем сервере (rphost) она должна обслуживаться. Если у вас несколько рабочих серверов с разными версиями платформы, вы просто выбираете нужный.
   • Если вы используете файловую базу или у вас более простая настройка, можно изменить путь в списке подключения к базам 1С на клиентских машинах. Например, если у вас было подключение к серверу Srvr="1c-8";Ref="rtc_ut_test_2";, и основной сервер 1С работает на 8.3.23.1739, а вы запустили дополнительный агент на порту 1541 на той же машине, но от платформы 8.3.22.1923, то можно было бы указать: Srvr="1c-8:1541";Ref="rtc_ut_test_2"; (если порты разные).

Как уточнил автор в сообщении 15, "с одной базой работает определенный Агент сервера. Но к 1 серверу БД (5 баз SQL) обращаются с разных платформ 1с." Это означает, что на одном физическом сервере могут быть запущены несколько экземпляров rphost, каждый из которых обслуживается своей версией платформы. Затем в настройках кластера 1С (или списка баз) можно указать, какой rphost (читай – какая версия платформы) будет обслуживать конкретную информационную базу.

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

Решение 2: Работа с пользовательскими настройками отчетов

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

Вариант 1: Полное удаление настроек отчетов

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

1. Причины: Пользовательские настройки отчетов могут содержать устаревшие или некорректно сохраненные данные, которые новая платформа 8.3.23.1739 не может правильно интерпретировать, что приводит к сбою при попытке их загрузки и применения.
2. Как удалить:
   • Через интерфейс 1С:
     • Зайдите в базу под администратором.
     • Откройте "Все функции" (обычно доступно через Главное меню -> Сервис -> Все функции или через горячую клавишу Ctrl+Shift+Alt+F).
     • Найдите раздел "Стандартные" и там "Удаление помеченных объектов". Проверьте, нет ли там помеченных на удаление настроек.
     • Более целевой вариант: через "Все функции" найдите "Регистры сведений" или "Справочники" связанные с хранением пользовательских настроек (например, ПользовательскиеНастройкиОтчетов, ХранилищеВариантовОтчетов или похожие объекты, зависящие от конфигурации). Здесь можно просмотреть и вручную удалить записи, относящиеся к проблемным отчетам или пользователям.
     • Также можно попробовать сбросить пользовательские настройки для конкретного пользователя через "Администрирование" -> "Настройки пользователей и прав" -> "Пользователи" -> выбрать пользователя -> "Настройки пользователя" -> "Сбросить настройки".
   • Через код (для разработчиков): Можно написать небольшую обработку, которая очистит соответствующие регистры сведений, хранящие настройки отчетов. Например, если настройки хранятся в регистре сведений ХранилищеВариантовОтчетов, код может выглядеть так:
     Скопировать код

     
     Запрос = Новый Запрос;
     Запрос.Текст = "ВЫБРАТЬ
                    |    ХранилищеВариантовОтчетов.Ссылка
                    |ИЗ
                    |    РегистрСведений.ХранилищеВариантовОтчетов КАК ХранилищеВариантовОтчетов
                    |ГДЕ
                    |    ХранилищеВариантовОтчетов.НаименованиеОтчета = &ИмяПроблемногоОтчета"; // Или просто удалить все
                     
     Запрос.УстановитьПараметр("ИмяПроблемногоОтчета", "ВедомостьПоТоварамНаСкладах"); // Пример
                     
     Выборка = Запрос.Выполнить().Выбрать();
     Пока Выборка.Следующий() Цикл
         // Получить объект и удалить его
         Попытка
             МенеджерЗаписи = РегистрыСведений.ХранилищеВариантовОтчетов.СоздатьМенеджерЗаписи();
             МенеджерЗаписи.Прочитать(); // Заполняем менеджер записи по ключевым полям выборки
             // В зависимости от структуры регистра, возможно, потребуется более точное определение записи
             // Например:
             // МенеджерЗаписи.Пользователь = Выборка.Пользователь;
             // МенеджерЗаписи.Отчет = Выборка.Отчет; и т.д.
             // Если это регистр с одной ссылкой на хранилище:
             ОбъектХранилища = Выборка.Ссылка.ПолучитьОбъект();
             ОбъектХранилища.Удалить();
             Сообщить("Удален вариант отчета: " + ОбъектХранилища.Представление());
         Исключение
             Сообщить("Ошибка при удалении варианта отчета: " + ОписаниеОшибки());
         КонецПопытки;
     КонецЦикла;
     

Несмотря на свою эффективность, этот метод приводит к потере всех пользовательских настроек, что, как отметил автор, "совсем не вариант" из-за их большого количества и ценности.

Вариант 2: Выборочная диагностика и удаление "битых" настроек

Это более деликатный подход, предложенный в сообщении 8, который позволяет сохранить большинство настроек и выявить только те, что вызывают проблему.

1. Процесс:
   • Выгрузка всех настроек в файл: Откройте проблемный отчет. В его форме, как правило, есть возможность сохранить пользовательские варианты настроек в файл (например, XML). Обычно это делается через меню "Настройки" -> "Прочие настройки" -> "Сохранить настройки" или "Варианты отчетов" -> "Сохранить вариант". Выгрузите все доступные пользовательские варианты отчетов в отдельные файлы или один общий, если это возможно.
   • Очистка всех настроек: После выгрузки временно удалите все пользовательские настройки отчета (как описано в Варианте 1). Убедитесь, что после этого отчет запускается без ошибок. Если запускается, это подтверждает, что проблема была именно в настройках.
   • Поочередная загрузка настроек: Теперь начните загружать сохраненные настройки по одному или небольшими группами. После загрузки каждой настройки или группы, попробуйте запустить отчет.
     • Если отчет падает после загрузки какой-либо настройки, вы идентифицировали "битую" настройку. Вы можете решить не загружать ее или попытаться пересоздать заново.
     • Продолжайте этот процесс, пока не загрузите все рабочие настройки.
2. Инструменты для работы с настройками:
   • В самой конфигурации 1С, в формах отчетов, всегда есть кнопки для сохранения и загрузки настроек (обычно это относится к текущему варианту или всем вариантам отчета).
   • Для более продвинутой работы можно использовать стандартные обработки 1С или написать свою, которая позволит массово выгружать и загружать настройки из конкретных регистров сведений, где они хранятся.

Этот метод требует больше времени и усилий, но позволяет минимизировать потери ценных пользовательских настроек.

Дополнительные меры и рекомендации

Помимо основных решений, есть несколько дополнительных шагов, которые мы всегда рекомендуем при возникновении подобных проблем, связанных с обновлением платформы или сбоями:

1. Очистка кэша 1С

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

   • На клиентских машинах: Мы рекомендуем очистить кэш 1С для каждого пользователя. Это делается путем удаления папок с временными файлами 1С, которые обычно находятся по путям:
     • %LOCALAPPDATA%\1C\1CE\
     • %APPDATA%\1C\1CE\

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

   • На сервере 1С (для клиент-серверного варианта): Необходимо перезапустить службу сервера 1С:Предприятия. Это очистит серверный кэш и заставит rphost процессы перечитать данные и конфигурации. В некоторых случаях может потребоваться ручное удаление содержимого папок кэша кластера сервера 1С, но обычно перезапуска службы достаточно.

2. Проверка актуальности конфигурации

   Иногда новые версии платформы требуют обновленных версий конфигураций. Хотя в данном случае проблема, судя по всему, в платформе, всегда стоит убедиться, что ваша конфигурация также актуальна и совместима с используемой версией платформы. Автором упоминалось, что обновление платформы было необходимо для БГУ и ЗУП. Убедитесь, что после установки платформы 8.3.22.1923, ваши конфигурации также обновлены до версий, официально поддерживающих эту платформу.

3. Обращение в техническую поддержку 1С

   Если проблема воспроизводится на типовой конфигурации и типовых данных (например, на полностью пустой, но обновленной до 8.3.23.1739 базе) и вы не смогли найти обходного пути, это может быть ошибкой в самой платформе, требующей внимания разработчиков "1С". В таком случае мы настоятельно рекомендуем обратиться в техническую поддержку "1С", предоставив им всю собранную информацию, включая логи дампа и описание шагов воспроизведения.

4. Поиск официальных исправлений (патчей)

   Компания "1С" регулярно выпускает патчи (исправления) для уже выпущенных версий платформы, которые устраняют выявленные ошибки. Мы рекомендуем проверять официальные источники "1С" (например, сайт поддержки пользователей) на наличие патчей для версии 8.3.23.1739. Возможно, для этой версии уже вышло или планируется исправление, которое решит вашу проблему.

В заключение, проблема «Неисправимой ошибки» при работе с отчетами после обновления платформы до 8.3.23.1739 является серьезным, но, как мы видим, решаемым вопросом. Самым надежным способом на текущий момент является использование стабильной версии платформы (например, 8.3.22.1923), возможно, с помощью механизма сосуществования различных версий агентов сервера 1С. Также мы рассмотрели варианты работы с пользовательскими настройками отчетов, которые могут быть источником проблемы. Всегда помните о необходимости очистки кэша и актуализации конфигурации, а в случае глубоких проблем — обращайтесь к официальной поддержке.