← На главную

Проблема потери данных при обновлении или реструктуризации базы данных в 1С:Предприятии 7.7 (особенно в формате DBF) является одной из самых опасных и, к сожалению, классических для этой платформы. Рассмотрим ситуацию: администратор добавляет новые реквизиты в шапку документа, запускает процесс сохранения изменений, а после завершения обнаруживает, что файлы таблиц (например, DH7430.dbf) имеют нулевой размер или содержат пустые записи. Проанализируем причины этого явления и выработаем надежный алгоритм безопасного обновления.

Механизм реструктуризации и папка NEWSTRU

Для понимания того, как происходит потеря данных, сначала разберем внутреннюю логику работы Конфигуратора 1С 7.7 при изменении структуры таблиц. Этот процесс автоматизирован и проходит через промежуточный этап с использованием временного каталога NEWSTRU.

Разберем этот процесс по шагам:

1. При нажатии кнопки «Сохранить» конфигуратор создает в каталоге базы данных временную папку NEWSTRU.
2. Внутри этой папки создаются пустые .dbf файлы с новой структурой, соответствующей обновленному файлу метаданных 1cv7.md.
3. Программа начинает последовательное чтение данных из старых файлов (в корне базы) и запись их в новые файлы (в NEWSTRU). При этом происходит конвертация типов, если они были изменены.
4. Если процесс копирования всех таблиц завершился без критических ошибок, 1С удаляет старые файлы в основном каталоге и перемещает на их место новые файлы из NEWSTRU.
5. В финале удаляются временные файлы и обновляется файл словаря данных 1cv7.dd.

Проанализируем слабое место этой цепочки. В сообщении лога мы видим: Create Table DH7430 и Open Table DH7430. Это означает, что система инициировала создание новой структуры. Однако, если в процессе чтения старых данных произойдет логический сбой, система может посчитать, что данных в исходной таблице просто нет.

Роль поврежденных индексов (CDX) в обнулении таблиц

Как выяснилось в ходе обсуждения (сообщение №21), основной причиной «исчезновения» данных стали битые индексы. Рассмотрим подробнее, как поврежденный индексный файл .cdx влияет на реструктуризацию.

Когда 1С 7.7 обращается к таблице DBF для копирования данных, она часто использует индекс для обхода записей. Если заголовок индекса или дерево ссылок повреждены, указатель чтения может мгновенно переместиться в конец файла (состояние EOF — End Of File). С точки зрения движка базы данных ситуация выглядит так: «Я попытался прочитать записи, их оказалось 0, я успешно закончил копирование 0 записей в новую таблицу».

В результате в папке NEWSTRU формируется абсолютно валидный, но пустой .dbf файл. Поскольку физической ошибки чтения (I/O Error) не возникло, система считает операцию успешной и заменяет вашу рабочую таблицу этим «пустым бланком».

Опасность Тестирования и Исправления после сбоя

Часто системные администраторы, заметив пропажу документов, совершают вторую критическую ошибку — запускают режим Тестирование и Исправление (ТиИ). Посмотрим, почему это губительно в данной ситуации.

В 1С 7.7 данные документа разделены: заголовки хранятся в таблице DH (Document Header), а строки — в таблице DT (Document Text). Если в результате реструктуризации обнулилась только таблица DH, то в DT данные всё еще физически присутствуют. Однако ТиИ при проверке ссылочной целостности увидит «сиротские» записи в DT, которые не ссылаются ни на один существующий заголовок в DH. По умолчанию ТиИ предложит «Очищать ссылки» или «Удалять объекты», что приведет к безвозвратному удалению содержимого табличных частей. После такого «лечения» восстановить данные будет на порядок сложнее.

Алгоритм безопасного обновления базы 1С 7.7

Чтобы избежать подобных ситуаций, выработаем правильный порядок действий при обновлении конфигурации, требующей реструктуризации:

1. Создание полной резервной копии. Никогда не полагайтесь на встроенные средства 1С. Скопируйте весь каталог базы данных целиком на другой физический носитель.
2. Принудительное удаление индексов. Это самый важный шаг. Перед запуском Конфигуратора для обновления удалите все файлы с расширением *.cdx из каталога базы. При входе в Конфигуратор или в режиме Предприятия система предложит восстановить индексы. Это гарантирует, что реструктуризация будет проходить по свежепостроенным, корректным индексам.
3. Проверка физической целостности. Желательно проверить .dbf файлы сторонними утилитами на предмет корректности заголовков (например, соответствие количества записей в заголовке реальному размеру файла).
4. Контроль свободного места. Убедитесь, что на диске достаточно места для создания копии всей базы в папке NEWSTRU. Нехватка места в момент переноса файлов — еще одна частая причина порчи данных.
5. Отключение антивируса. На время реструктуризации следует отключить антивирусное сканирование, так как блокировка временного файла в момент его переноса из NEWSTRU в корень базы может привести к ошибке доступа и «потери» файла.

Что делать, если данные уже пропали?

Если вы обнаружили пустые таблицы, а полноценного бэкапа нет, проанализируем возможные пути спасения:

Во-первых, загляните в каталог базы. Возможно, там осталась папка NEWSTRU. Как отмечено в сообщении №14 и №17, если процесс упал или был прерван, там могут лежать временные файлы, которые еще не были перенесены или удалены. В этой папке могут находиться файлы в их «здоровом» виде до или сразу после изменений.

Во-вторых, если файлы в основном каталоге имеют размер 0 байт, это означает, что старые файлы были удалены файловой системой. В этом случае могут помочь утилиты по восстановлению удаленных файлов (например, R-Studio). Важно ничего не записывать на этот диск до окончания попыток восстановления.

В-третьих, можно попробовать восстановить заголовки документов программным путем, если сохранились записи в журнале регистрации 1cv7.mlg и данные в таблицах DT. Хотя это трудоемкий процесс, он позволяет восстановить хотя бы часть информации за «потерянные» полдня работы пользователей.

Рассмотрим пример того, как можно проверить целостность словаря данных 1cv7.dd. Если идентификаторы объектов в .md файле и в .dd файле разошлись, 1С может начать создавать таблицы под новыми именами, игнорируя старые. Всегда сравнивайте структуру, которую ожидает система, с тем, что фактически находится на диске.

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