Ситуация, когда документ был успешно создан, проведен и даже распечатан, а затем бесследно исчез из общего журнала, является классическим признаком нарушения целостности файловой базы данных (формат DBF) в 1С:Предприятии 7.7. Особенно тревожным сигналом является расхождение в журнале регистрации, когда идентификатор объекта указывает на один тип документа (например, «Чек ККМ»), а текстовое представление — на другой («Заказ покупателя»).
В данной статье мы подробно разберем, почему возникают такие сбои, как правильно восстановить работоспособность базы и какие профилактические меры помогут избежать потери данных в будущем.
Прежде чем приступать к активным действиям, проанализируем механику записи данных в 1С 7.7. В файловой версии информация о документе распределяется по нескольким таблицам:
_1SJOURN) — здесь хранится краткая информация: дата, номер, тип документа, пометка удаления и ссылка на автора.DH*, например, DH123) — здесь хранятся основные реквизиты конкретного вида документа.DT*) — здесь содержатся строки документа.*.cdx) — это «путеводители», которые позволяют системе быстро находить нужные записи в .dbf файлах.Рассмотрим ситуацию, возникшую у автора темы. Если журнал регистрации показывает противоречивые данные, это означает конфликт идентификаторов. При аварийном завершении работы (отключение света, сбой сети) счетчик внутренних ID может «откатиться» назад. Система выдает новому документу ID, который уже был когда-то присвоен. Если при этом произошел сбой в индексах, 1С начинает путать записи, обращаясь по одной ссылке к разным таблицам.
Первое, что необходимо сделать при обнаружении пропажи документов — это полная переиндексация. Важно понимать: штатное предложение 1С «Переиндексировать?» при входе в базу после сбоя не всегда эффективно. Рассмотрим более надежный метод:
.cdx. Сами данные (файлы .dbf) трогать нельзя!Проанализируем результат: если документы появились — проблема была исключительно в «битых» индексах. Если же вместо документов в журнале появилась надпись <Объект не найден>, переходим к следующему шагу.
Появление надписи <Объект не найден> означает нарушение логической целостности. Запись о документе в общем журнале (_1SJOURN) есть, а физической записи в таблице шапки документа (DH*) — нет. Такое случается, если транзакция записи была прервана на середине.
Для исправления ситуации воспользуемся штатным механизмом «Тестирование и исправление ИБ»:
Если пропавшие документы жизненно важны, выясним, нельзя ли их «воскресить» напрямую из DBF. Иногда запись помечается как удаленная, но физически остается в файле до тех пор, пока не будет выполнена процедура «Упаковки».
Проанализируем структуру таблицы конкретного документа (например, DH123.dbf, где 123 — внутренний номер таблицы «Заказ покупателя»):
Важно: Этот метод требует глубокого понимания структуры таблиц 1С 7.7. Не делайте этого без опыта и без резервной копии!
Рассмотрим технические причины, которые приводят к таким «глюкам» в современных условиях:
Если ваша база 1С 7.7 лежит на сервере с Windows Server 2008 и выше, а пользователи работают на Windows 7/10/11, причиной пропажи данных часто является кэширование сетевого трафика. Механизмы SMB2/3 могут «придерживать» запись данных в файл .dbf. В итоге программа считает, что данные записаны, а в реальности они остались в кэше клиента и пропали при закрытии сессии.
Решение: Рекомендуется отключить кэширование каталогов (Directory Caching) на сервере или ограничить работу сетевого протокола версией SMB 1.0 (хотя это снижает безопасность).
Помните, что в 1С 7.7 существует жесткое ограничение: размер любого .dbf файла не может превышать 2 ГБ. Особое внимание уделите файлу _1SJOURN.dbf. При приближении к этому порогу база начинает вести себя непредсказуемо, и документы могут исчезать массово.
Чтобы минимизировать риск, внедрим следующие правила:
Подводя итог: если в вашей 1С 7.7 пропали документы, не паникуйте. Последовательная переиндексация и грамотное использование инструментов тестирования позволяют в большинстве случаев либо вернуть данные, либо корректно «вычистить» базу от ошибок.