Почему в 1С 7.7 (DBF) пропадают документы за несколько дней после сбоя сервера и как их восстановить?

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

Выясняем причину: почему данные «исчезли», хотя они записывались

Проанализируем механику работы 1С 7.7 с файлами формата DBF. Когда пользователь сохраняет документ, система выполняет несколько последовательных операций на уровне файловой системы:

1. Данные дописываются в конец соответствующего файла таблицы (например, DH2742.dbf).
2. Обновляется файл индекса (.cdx).
3. В заголовке (Header) самого DBF-файла обновляется поле, отвечающее за количество записей.

Важный технический нюанс: операционная система часто кэширует запись заголовка файла. Если в момент записи произошел критический сбой, сами строки данных могут физически успеть записаться на диск (тело файла увеличится), но заголовок останется старым. Когда 1С открывает такой файл, она считывает из заголовка, что в таблице, например, «1000 записей». Все данные, которые идут после 1000-й строки, программа просто игнорирует, считая их «мусором» или свободным местом. Именно поэтому переиндексация штатными средствами часто не помогает: индексатор тоже видит только то количество строк, которое указано в «испорченном» заголовке.

Шаг 1: Анализ структуры базы через файл словаря

Чтобы понять, какие файлы отвечают за пропавшие данные, нам понадобится файл 1cv7.dd. Это текстовый словарь данных, который находится в корневом каталоге базы. Разберем, как его использовать:

Откроем 1cv7.dd любым текстовым редактором (например, Notepad++). Найдем описание нужного документа. В теме упоминался «Заказ поставщику». Поиском по названию находим соответствующую таблицу:

#==TABLE no 75     : Документ (Мн.ч.) ЗаказПоставщику
# Name     |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=DT2742   |Документ (Мн.ч.) ЗаказПоставщи|A          |DT2742     |1         
#-----Fields-------
# Name      |Descr               |Type|Length|Precision
F=IDDOC     |ID Document's       |C   |9     |0        
F=LINENO    |LineNo              |N   |4     |0        

Здесь DT2742 — это таблица табличной части, а DH2742 (Document Header) — таблица шапки документа. Проанализируем даты изменения этих файлов в проводнике Windows. Если дата изменения файла — вчерашняя, а документы видны только за позавчера, значит, данные внутри файла есть, но они «скрыты» поврежденным заголовком.

Шаг 2: Проверка главной таблицы журнала документов 1SJOURN

Все документы в 1С 7.7 регистрируются в общей таблице 1SJOURN.dbf. Если записи о документах пропали из этой таблицы, они не появятся в журналах 1С, даже если физически присутствуют в таблицах DH и DT. Рассмотрим структуру записи в 1SJOURN, которую можно увидеть через DBF-вьюер:

1. DATE — дата документа.
2. TIME — время документа.
3. IDDOC — уникальный идентификатор, связывающий журнал с таблицами шапки и части.
4. CLOSED — флаг проведения документа.

Если при просмотре файла 1SJOURN.dbf специализированной утилитой мы видим записи за «пропавшие» даты, но 1С их не показывает — дело однозначно в заголовке файла.

Шаг 3: Восстановление «пропавших» строк через правку заголовка

Для восстановления видимости данных нам потребуется DBF-редактор, умеющий пересчитывать количество записей (например, DBF Commander или WinDBFView). Рассмотрим алгоритм действий:

1. Сделаем полную резервную копию всей папки с базой данных!
2. Откроем «подозрительный» файл (например, 1SJOURN.dbf) в редакторе.
3. Воспользуемся функцией «Recalculate record count» или «Fix Header». Утилита сравнит физический размер файла с размером одной записи и обновит число строк в заголовке.
4. Сохраним изменения.
5. Обязательно удалим все индексные файлы .cdx в каталоге базы.
6. Запустим 1С в монопольном режиме для выполнения переиндексации.

Шаг 4: Разбор проблемы «старых комментариев» (таблица 1SSTRIN)

Рассмотрим ситуацию, описанную в сообщении 33: после восстановления в новых документах стали появляться комментарии от старых (удаленных или пропавших) документов. Это происходит из-за особенностей хранения длинных строк в 1С 7.7.

Тексты неограниченной длины хранятся в отдельной таблице 1SSTRIN.dbf. В основных таблицах (DH) хранятся лишь ссылки (ID) на записи в этой таблице. Проанализируем механизм сбоя:

1. При создании новых документов система берет следующий свободный ID из таблицы 1SSYSTEM.
2. После сбоя счетчик в 1SSYSTEM мог «откатиться» назад, а таблица 1SSTRIN могла сохранить записи за пропавшие дни.
3. В итоге новый документ получает старый ID, обращается к 1SSTRIN и подтягивает текст, который предназначался для документа, созданного до аварии.

Выясним, как это лечить: в данной ситуации поможет только «Типовая выгрузка/загрузка данных» (через формат .dat в Конфигураторе), которая пересоберет связи и очистит неиспользуемые записи в системных таблицах. Однако это сработает только в том случае, если логическая целостность базы еще не окончательно разрушена.

Итоговые рекомендации

Проанализировав ситуацию, мы пришли к выводу, что данные в файловой 1С 7.7 редко исчезают бесследно. Чаще всего они просто становятся невидимыми для движка БД. Если вы столкнулись с подобным:

• Ни в коем случае не начинайте сразу вводить документы заново в этой же базе.
• Проверьте фактический размер DBF-файлов и сравните его с размером в архивной копии.
• Попробуйте восстановить заголовки файлов 1SJOURN, 1SSTRIN и таблиц конкретных видов документов.
• Помните, что Syslog (файл 1cv7.mlg) — это текстовый файл, и наличие в нем записей DocWrite подтверждает, что данные физически доходили до диска.

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