Обновление крупных прикладных решений на платформе 1С:Предприятие 8.3 (таких как «Бухгалтерия предприятия 3.0», «ERP Управление предприятием» или «Комплексная автоматизация») — процесс ресурсоемкий и технически сложный. Иногда в процессе штатного обновления администраторы и программисты сталкиваются с критическими сбоями, наиболее коварным из которых является «Ошибка при выполнении файловой операции».
Ситуация усугубляется, когда после попыток исправить ошибку «вручную» в базе данных нарушается связь с конфигурацией поставщика: версии конфигурации и поддержки перестают совпадать, а свойства некоторых объектов метаданных (например, форм документов или макетов) при сравнении отображаются как абсолютно пустые. В этой статье мы подробно разберем причины возникновения этой проблемы и рассмотрим пошаговые методы восстановления работоспособности базы данных.
Для того чтобы эффективно устранить ошибку, проанализируем природу ее возникновения. Практический опыт администрирования баз данных 1С показывает, что «Ошибка при выполнении файловой операции» в сочетании с пустыми свойствами форм указывает на серьезное повреждение логической структуры конфигурации. Рассмотрим ключевые факторы, провоцирующие этот сбой:
Config (и ConfigSave для сохраненной, но не примененной конфигурации) в виде сжатых двоичных файлов (потоков/streams). Если при записи или чтении этих данных произошел сбой, платформа теряет доступ к конкретным объектам, из-за чего свойства форм в окне сравнения и объединения отображаются пустыми.%TEMP%. Если антивирусное ПО или защитник Windows сканируют эти файлы «на лету», происходит кратковременная блокировка чтения/записи, приводящая к сбою файловой операции в 1С.Обычные средства диагностики, такие как внешняя утилита проверки физической целостности файлов chdbfl.exe или встроенный инструмент «Тестирование и исправление» (ТиИ), в данном случае бессильны. Они проверяют физическое состояние таблиц базы, но не десериализуют и не проверяют внутреннее содержимое сжатых XML-потоков конфигурации. Рассмотрим эффективные методы решения проблемы.
Прежде чем приступать к лечению базы данных, нам необходимо точно определить, какой именно объект метаданных поврежден. Для этого выполним процедуру выгрузки файлов конфигурации:
C:\Conf_Unpack\) и укажем ее в качестве целевого каталога.В ходе этой операции платформа последовательно считывает из СУБД все объекты метаданных, распаковывает их и записывает на диск в виде XML-файлов и модулей кода. В момент, когда система наткнется на поврежденный двоичный поток, процесс прервется той самой «Ошибкой при выполнении файловой операции». Посмотрев на имя последнего успешно записанного файла или на сообщение об ошибке, мы сможем однозначно идентифицировать поврежденный документ, справочник или форму.
Если в процессе неквалифицированных действий у вас сбились версии конфигурации и поддержки (например, конфигурация базы данных обновилась до релиза 3.0.73.46, а на поддержке осталась версия 3.0.71.89), стандартное автоматическое обновление работать не будет. Нам потребуется восстановить правильную структуру поддержки с помощью подготовленного файла конфигурации поставщика (cf).
Для реализации этого метода нам понадобится чистый, неповрежденный файл конфигурации (cf) точно того же релиза, на котором сейчас находится ваша рабочая база данных (или релиза, непосредственно предшествующего сбою). Рассмотрим этот процесс по шагам:
3.0.71.89) и загрузим его в созданную пустую базу.1c_clean.cf будет гарантированно чистым и полностью находиться на замке (на поддержке поставщика).1c_clean.cf.F7.Этот метод позволяет корректно связать вашу рабочую базу данных с эталонной конфигурацией поставщика без изменения самих учетных данных пользователей.
Если ваша база данных работает под управлением СУБД (Microsoft SQL Server, PostgreSQL, IBM DB2), мы можем применить более радикальный и действенный способ восстановления «битых» метаданных. Этот метод полностью очищает таблицы хранения программного кода конфигурации и перезаписывает их заново из эталонного файла.
Внимание! Перед выполнением любых операций на уровне СУБД убедитесь в наличии актуальной резервной копии базы данных, созданной средствами SQL Server Management Studio или pgAdmin.
Выполним следующие действия:
Config и ConfigSave. Для этого используем следующий код:
-- Очистка таблиц конфигурации базы данных
TRUNCATE TABLE dbo.Config;
TRUNCATE TABLE dbo.ConfigSave;
cf того релиза, на котором находилась база до сбоя.F7). Платформа заново пересоздаст все внутренние индексы и логические связи метаданных в очищенных таблицах СУБД.Этот способ гарантированно избавляет базу данных от любых скрытых логических повреждений структуры метаданных и битых двоичных потоков.
Если ваша информационная база работает в файловом режиме (файл 1Cv8.1CD), прямое редактирование таблиц через СУБД выполнить крайне сложно. В таком случае оптимальным решением является перенос чистых учетных данных (документов и справочников) в созданную «с нуля» пустую базу данных с исправной конфигурацией.
Для миграции данных мы воспользуемся проверенной универсальной обработкой «Выгрузка и загрузка данных XML», которую можно найти на диске информационно-технологического сопровождения (ИТС) или в личном кабинете портала 1С. Разберем этот процесс по шагам:
F7).ВыгрузкаЗагрузкаДанныхXML.epf.C:\Backup\data_transfer.xml) и нажмем кнопку «Выгрузить».ВыгрузкаЗагрузкаДанныхXML.epf, перейдем на вкладку «Загрузка», укажем путь к созданному XML-файлу и нажмем кнопку «Загрузить данные».Этот метод полностью исключает перенос поврежденных элементов метаданных, так как XML-схема переносит исключительно прикладные данные объектов (реквизиты, табличные части, движения документов), восстанавливая их ссылочную целостность в новой, заведомо исправной структуре таблиц.
Иногда при попытке применить изменения конфигурации (после успешного восстановления связи с поддержкой) платформа выдает ошибку вида: «Запись с такими ключевыми полями существует». Это означает, что в базе данных появились дублирующиеся записи в уникальных регистрах сведений, что блокирует процесс реструктуризации таблиц при обновлении.
Чтобы решить эту проблему, выполним следующие действия:
После завершения тестирования и исправления повторим попытку обновления конфигурации — процесс должен пройти в штатном режиме без ошибок реструктуризации.
Чтобы в дальнейшем минимизировать риск возникновения «Ошибки при выполнении файловой операции», проанализируем и настроим окружение вашего сервера или рабочего компьютера:
%userprofile%\AppData\Local\1C\1Cv8
%userprofile%\AppData\Roaming\1C\1Cv8
%TEMP% в список исключений сканирования вашего антивирусного программного обеспечения. Это исключит блокировку временных файлов платформы сторонними процессами в момент реструктуризации таблиц.Мы подробно разобрали природу возникновения ошибок файловых операций, методы восстановления поврежденной конфигурации с поддержки, а также низкоуровневые способы реанимации баз данных 1С. Регулярное создание резервных копий и соблюдение технических регламентов при обновлении позволят вам избежать подобных критических ситуаций в будущем.