Работа со старыми базами 1С:Предприятие 7.7 часто напоминает реанимацию «пациента», который должен был уйти на покой еще десять лет назад. Однако критические сбои в таких системах — не редкость, особенно когда речь идет о файловых версиях (DBF). Рассмотрим ситуацию, когда в базе начинают происходить странные вещи: пропадают документы из журналов, очищаются движения в регистрах, а штатное тестирование и исправление (ТиИ) выдает ошибки уникальности идентификаторов. Проанализируем причины таких сбоев и разберем пошагово, как восстановить работоспособность системы.
Прежде чем приступать к любым манипуляциям, обязательно создаем архивную копию базы. Даже если она уже «сломана», текущее состояние может быть лучше того, что получится после неудачных попыток лечения. Первым делом выполним стандартную очистку «мусора», который часто мешает корректной работе движка 1С 7.7.
*.cdx. Это заставит систему при следующем запуске в монопольном режиме полностью перестроить индексы.SYSLOG. В ней хранится журнал регистрации 1CV7.MLG. Если этот файл разрастается до нескольких гигабайт, он начинает тормозить работу и может вызывать ошибки при записи новых транзакций.*.tmp, *.lck, а также DBF-файлы, имена которых начинаются с символа тильды (например, ~1S*.dbf).После очистки запустим 1С в монопольном режиме. Произойдет автоматическая переиндексация. Если документы вернулись в журналы, но записи в регистрах по-прежнему отсутствуют — переходим к следующему этапу.
Ошибка «Проверка уникальности внутреннего идентификатора» является критической для ссылочной целостности базы. В 1С 7.7 каждый объект (документ, элемент справочника) имеет уникальный 13-символьный ID в 36-ричной системе исчисления. Если два документа получают одинаковый ID, система перестает понимать, к какому из них относятся записи в таблицах движений.
Разберем, как исправить эту ошибку, если штатное ТиИ не помогает:
ПриходнаяНакладная. Номер 0000000001(28.08.24). Вн. идентификатор 1SL6. Это означает, что идентификатор 1SL6 уже кем-то занят.1SJOURN.DBF.0-9 и A-Z.DH* для заголовка и DT* для табличной части), а также в таблицах движений регистров RA*. Если мы меняем ID в 1SJOURN, его нужно синхронно заменить во всех связанных таблицах, иначе связи разорвутся окончательно.Если документов с нарушенным ID немного, иногда проще пометить их на удаление, создать новые (копии) и удалить «битые» оригиналы после переноса данных. Это позволит системе автоматически сгенерировать правильные уникальные идентификаторы.
Если документы в журнале видны, но их «движения» (проводки по регистрам) исчезли, это может указывать на повреждение физических таблиц RA* (таблицы движений) или RG* (таблицы итогов).
Выясним причину: если записи в RA* физически существуют, но отчеты показывают пустоту, значит, проблема в итогах. Проанализируем шаги по восстановлению:
В конфигураторе выберем пункт «Администрирование» — «Тестирование и исправление». Установим галочку «Пересчет итогов». В отличие от простого перепроведения, эта операция полностью очищает таблицы RG* и заново вычисляет остатки на основании данных из RA*. Это обязательный шаг, если база «посыпалась».
Если же записи пропали и из таблиц RA*, единственный способ их вернуть — программное перепроведение документов. Здесь есть два основных подхода:
Рассмотрим этот вариант как наиболее надежный. Установим ТА на самый старый документ, требующий перепроведения. После этого запустим групповое проведение. Это заставит систему последовательно пересчитывать остатки, что исключит логические перекосы в регистрах.
Посмотрим на такие инструменты, как Unijourn.ert или самописные «роботы» перепроведения. Робот может запускаться в ночное время, анализировать границу последовательности и восстанавливать её порциями (например, по одному месяцу). Это полезно, если база огромная и проведение всех документов занимает десятки часов.
// Пример логики робота для восстановления последовательности
ГП = Последовательность.ОсновнаяПоследовательность.ПолучитьГраницу();
Док = СоздатьОбъект("Документ");
Док.ВыбратьДокументы(ГП, РабочаяДата());
Пока Док.ПолучитьДокумент() = 1 Цикл
Если Док.Проведен() = 1 Тогда
Попытка
Док.Провести();
Исключение
Сообщить("Ошибка в документе: " + Док.ТекущийДокумент());
КонецПопытки;
КонецЕсли;
КонецЦикла;
Часто «монстр Франкенштейна» (старая база 7.7) начинает разваливаться из-за работы на современных ОС (Windows 10, 11 или Windows Server 2019+). Проанализируем технические причины:
SMB и Opportunistic Locking (Oplocks): Если база лежит на сетевом диске, современные протоколы SMB кэшируют запись. Это приводит к тому, что 1С считает данные записанными, хотя физически в DBF-файл они еще не попали. При малейшем сетевом лаге индексы .cdx «разлетаются», а транзакции выпадают. На сервере и клиентских машинах крайне рекомендуется отключать механизм Oplocks через реестр Windows.
Кодировки и OrdNoChk.res: На 64-битных системах 1С 7.7 часто требует переиндексации при каждом входе из-за разницы в сортировке строк. Для решения этой проблемы используйте файл-заглушку OrdNoChk.res в каталоге программы или примените соответствующие патчи для библиотек bkend.dll.
Если база ведет себя непредсказуемо даже после всех манипуляций, возможно, поврежден сам файл метаданных 1Cv7.MD. В таких случаях мы можем применить стратегию «трансплантации»:
1Cv7.MD из старой базы..dat. Этот метод хорош тем, что 1С при загрузке создает объекты с нуля, присваивая им новые чистые ID и заново выстраивая все индексы.Подводя итог, восстановление 1С 7.7 — это всегда итерационный процесс. Сначала лечим структуру (индексы и временные файлы), затем исправляем ссылочную целостность (уникальные ID) и только в конце восстанавливаем экономические данные через пересчет итогов и перепроведение документов. И помните: лучшая профилактика подобных проблем — это ежедневное резервное копирование и своевременный переход на современные версии платформы.