Ситуация, когда в процессе обновления конфигурации происходит аварийное завершение работы программы (дамп), является одной из самых опасных для целостности данных. В этот момент 1С выполняет реструктуризацию таблиц базы данных: изменяет состав полей, индексов и связей. Если процесс прерывается, база остается в «промежуточном» состоянии — часть метаданных обновлена, а физические таблицы могут быть повреждены или не соответствовать новой структуре. Рассмотрим подробно, как действовать в такой ситуации, чтобы вернуть данные и восстановить работоспособность системы.
Прежде чем приступать к любым манипуляциям, даже если база кажется безнадежно «битой», необходимо сделать копию текущего состояния базы. Скопируйте файл 1Cv8.1CD (для файловой базы) или сделайте бэкап средствами SQL Server. Помните, что каждое последующее действие по исправлению (особенно Тестирование и исправление) может привести к безвозвратному удалению записей, которые система посчитает «лишними» или «ошибочными». Сохранив текущий «битый» вариант, вы оставляете себе шанс на извлечение данных специализированными утилитами в будущем.
Разберем ситуацию, почему документы могут быть видны в регистрах, но не отображаться в динамических списках (списках документов). Часто причиной является повреждение локального кэша метаданных на стороне клиента. Программа «помнит» старую структуру, которая конфликтует с текущим состоянием базы.
Выполним следующие действия для очистки кэша:
%AppData%\1C\1Cv8 и %LocalAppData%\1C\1Cv8.Если после этого документы появились — проблема была локальной. Если нет — переходим к глубокому лечению структуры.
Для файловых баз данных существует встроенная утилита chdbfl.exe. Проанализируем, почему её нужно использовать первой, еще до входа в Конфигуратор. Эта утилита работает на уровне файловой системы и формата .1CD, не используя движок самой платформы 1С. Она способна восстановить заголовки таблиц и страниц, которые «ослепшая» платформа просто не видит.
Алгоритм работы:
bin установленной платформы (например, C:\Program Files\1cv8\8.3.x.x\bin\chdbfl.exe).Если физическая целостность в норме, но данные в списках отсутствуют или регистры «врут», воспользуемся встроенным механизмом Тестирование и исправление. Выясним причину неверных остатков — скорее всего, нарушены итоги регистров накопления или разрушены индексы.
В Конфигураторе выберем пункт Администрирование — Тестирование и исправление. Рекомендуется выбирать следующие параметры:
Важно: В блоке «При наличии ссылок на несуществующие объекты» лучше выбрать «Не изменять», чтобы сначала оценить масштаб проблемы через отчет об ошибках, и только потом принимать решение об очистке.
Посмотрим на пример радикального, но эффективного способа «пересобрать» базу. Операция выгрузки в файл .dt и последующей загрузки в новую чистую базу заставляет платформу полностью перезаписать структуру данных.
Проанализируем этот процесс:
Этот метод помогает избавиться от «фантомных» ошибок в структуре таблиц, которые не смогла исправить утилита chdbfl.exe.
Если ошибка «нарушена целостность структуры конфигурации» сохраняется, это означает, что поврежден заголовок метаданных. В этом случае нам поможет файл конфигурации .cf из старого бэкапа (даже 3-недельной давности, если структура метаданных с тех пор не менялась кардинально).
Разберем по шагам:
1cv8.cf).Если стандартные средства не видят документы, но мы знаем, что они там были, можно воспользоваться инструментом Tool_1CD. Это сторонняя утилита, которая позволяет просматривать таблицы базы данных напрямую.
Рассмотрим сценарий спасения данных:
Tool_1CD._Document123).XML или CSV.Пример кода для программного создания документа на основе выгруженных данных:
НовыйДок = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
НовыйДок.Дата = ДатаИзФайла;
НовыйДок.Номер = НомерИзФайла;
// Заполнение табличных частей...
НовыйДок.Записать(РежимЗаписиДокумента.Запись);
Если после всех манипуляций документы за последние 3 недели так и не появились, придется прибегнуть к частичному восстановлению:
Универсальный обмен данными в формате XML. Если повреждены только индексы, эта выгрузка может сработать.Проанализировав ситуацию, мы видим, что отсутствие регулярных бэкапов превращает технический сбой в серьезную проблему. Выясним причину: почему дамп произошел именно при добавлении макета? Возможно, недостаточно места на диске или возникли проблемы с правами доступа. В будущем обязательно настройте ежедневное автоматическое копирование базы, чтобы не тратить 4 дня на поиск «пропавших» документов.