В процессе администрирования и сопровождения систем на платформе «1С:Предприятие» иногда возникает необходимость выполнить откат (даунгрейд) конфигурации на более ранний релиз. Это может быть связано с обнаружением критических ошибок в новом обновлении, несовместимостью с кастомными доработками или поспешным решением об обновлении без предварительного тестирования.
Однако простое «накатывание» файла конфигурации (.cf) предыдущей версии часто прерывается системной ошибкой. Платформа выдает критический сбой реструктуризации базы данных, сообщая, что записи в каком-либо регистре сведений не уникальны. В этой статье мы подробно разберем причины этой проблемы и рассмотрим надежные практические методы ее решения без потери накопленных данных.
Для того чтобы эффективно бороться с ошибкой, проанализируем физику процесса на уровне базы данных. В системе «1С:Предприятие» уникальность записей в регистре сведений (как в периодическом, так и в непериодическом) гарантируется уникальным индексом СУБД. Этот индекс строится по набору всех ключевых полей — то есть измерений регистра (а для периодических регистров — дополнительно по периоду).
При переходе на более раннюю версию конфигурации часто меняется структура метаданных этого регистра. Выясним, почему именно возникает конфликт:
Организация или Склад, а в старой версии его не существовало.Ниже мы рассмотрим пять способов решения этой проблемы, начиная от самых простых и заканчивая продвинутыми методами работы непосредственно с СУБД.
Рассмотрим самый очевидный и безопасный метод. Если перед обновлением базы данных была создана архивная копия (файл .dt или бэкап средствами СУБД), лучшим решением будет вернуться к ней.
Разберем по шагам, почему этот вариант наиболее предпочтителен:
Если в обновленной базе пользователи уже успели поработать и внести новые документы, не стоит отчаиваться. Мы можем восстановить архивную копию в новую пустую базу, а затем перенести в нее только те документы и справочники, которые были созданы за период работы в ошибочной конфигурации. Для этого отлично подойдет встроенная обработка ВыгрузкаЗагрузкаДанныхXML.epf или правила обмена в «1С:Конвертация данных».
Проанализируем ситуацию, когда бэкапа нет или объем введенных данных слишком велик для ручного переноса, а очистить регистр просто необходимо для успешного завершения обновления.
Мы можем использовать метод временного удаления данных проблемного регистра. Выполним следующие шаги:
НаборЗаписей = РегистрыСведений.ИмяПроблемногоРегистра.СоздатьНаборЗаписей();
// Отборы не устанавливаем, чтобы очистить регистр полностью
НаборЗаписей.Записать(Истина);
.cf-файл). Поскольку регистр теперь пуст, реструктуризация таблиц на уровне СУБД пройдет без единой ошибки.При загрузке в регистр с уменьшенным количеством измерений записи, содержащие дубли, автоматически «схлопнутся» (более поздние записи перезапишут более ранние), и структура регистра будет приведена к корректному виду.
Если информационная база развернута на сервере под управлением MS SQL Server или PostgreSQL, а размер проблемного регистра исчисляется миллионами записей, очистка штатными средствами «1С» может привести к зависанию системы. В таком случае очистку можно произвести напрямую через СУБД.
Важно: Перед выполнением любых операций напрямую в СУБД обязательно создайте резервную копию базы данных средствами SQL!
Выполним процедуру по шагам:
ПолучитьСтруктуруХраненияБазыДанных(). Напишем и запустим небольшой код:
ТаблицыБД = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого СтрокаТаблицы Из ТаблицыБД Цикл
Если Найти(СтрокаТаблицы.ИмяМетаданных, "РегистрСведений.ИмяПроблемногоРегистра") > 0 Тогда
Сообщить("Имя таблицы в СУБД: " + СтрокаТаблицы.ИмяТаблицыХранения);
КонецЕсли;
КонецЦикла;
_InfoRg12345. Откроем консоль управления вашей СУБД (SQL Server Management Studio или pgAdmin).TRUNCATE выполняется мгновенно и не забивает логи транзакций):
TRUNCATE TABLE dbo._InfoRg12345;
Если ваша конфигурация находится на поддержке поставщика, обычная загрузка старого файла .cf может нарушить логику последующих обновлений. Платформа обновит основную конфигурацию, но в системных таблицах конфигурация поставщика останется новой, что вызовет путаницу при следующих обновлениях.
Рассмотрим правильный алгоритм действий для сохранения корректного статуса поддержки:
.cf-файл нужной вам старой версии).Если вы хотите избежать любых скрытых ошибок реструктуризации, наиболее надежным (хоть и трудоемким) ручным методом является миграция данных в абсолютно чистую базу.
Разберем данный сценарий:
ВыгрузкаЗагрузкаДанныхXML.epf.Такой подход гарантирует 100% чистоту базы данных от различного конфигурационного мусора, который мог остаться после некорректно выполненных обновлений.
В заключение проанализируем еще один важный технический нюанс. При глубоком даунгрейде (например, при откате конфигурации на несколько лет назад) старая конфигурация может не запуститься на текущей новой версии платформы «1С:Предприятие». Это может приводить к ошибкам формата потока или аварийному завершению работы приложения.
В свойствах конфигурации обязательно обратите внимание на свойство «Режим совместимости». Если вы откатываетесь на старый релиз, проверьте, какое значение режима совместимости там установлено, и при необходимости установите соответствующую версию платформы 1С на рабочие компьютеры пользователей.