← На главную

Ситуация, когда в журнале документов 1С 7.7 внезапно появляются два одинаковых документа с разными номерами или авторами, но при попытке удалить один «страдает» другой — это классический симптом повреждения структуры базы данных или коллизии в распределенной информационной базе (УРБД). В этой статье мы подробно разберем, почему возникают такие «фантомы» и как восстановить работоспособность системы файловой версии на платформе DBF/CDX.

Проанализируем причины возникновения проблемы

Прежде чем приступать к активным действиям, нам необходимо понять механику сбоя. В 1С 7.7 данные документа распределены по нескольким таблицам:

1. 1SJOURN.dbf — общий журнал, где хранится ссылка на документ, его дата, номер и идентификатор автора.
2. DHxxxx.dbf — таблица шапки конкретного вида документа (где xxxx — уникальный код вида документа из файла 1cv7.dd).
3. DTxxxx.dbf — таблица табличной части документа.

Разберем основные сценарии появления дублей:

• Коллизия IDDOC в УРБД: Каждый документ имеет внутренний идентификатор IDDOC. Если в разных периферийных базах настроены одинаковые префиксы, система может создать два разных документа с одним и тем же внутренним ID. При обмене эти записи «накладываются» друг на друга.
• Сбой индексов (CDX): Индексные файлы могут «запутаться», указывая из разных строк журнала на одну и ту же физическую запись в таблице шапки.
• Обрыв транзакции: Если в момент записи произошел технический сбой (скачок напряжения, сетевая ошибка), запись может появиться в журнале, но не прописаться в основных таблицах данных, или наоборот.
• Превышение размера DBF: Когда размер файла приближается к 1–2 ГБ, механизм смещений в DBF начинает работать некорректно, что приводит к хаотичным ошибкам чтения и записи.

Способ 1. Восстановление через механизмы УРБД (Решение автора)

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

Важно: Перед любыми манипуляциями обязательно создайте архивную копию всей папки с базой данных!

Выполним следующие шаги:

1. Проведем полный цикл обмена данными между базами, чтобы максимально синхронизировать текущие изменения.
2. В центральной базе убедимся, что «лишних» документов нет.
3. Скопируем из центральной базы в проблемную периферийную все файлы с расширением .dbf, кроме системных файлов, отвечающих за настройки распределенки и константы.
4. Исключаем из копирования: 1SConst.dbf, 1SSystem.dbf, 1SUPDTS.dbf, 1SDWNLDS.dbf и 1SDBSET.dbf. Эти файлы хранят уникальные идентификаторы текущей базы и историю обменов, их замена «убьет» связь между базами.
5. В папке периферийной базы удалим все индексные файлы .cdx.
6. Запустим 1С в монопольном режиме для автоматического восстановления индексов.

Способ 2. Ручное редактирование таблиц DBF

Если автоматические методы не помогают, нам придется «оперировать» базу вручную. Для этого потребуется DBF-редактор, который корректно работает со старым форматом dBase IV (например, плагин LookDBF для Far Manager или старые версии MS Access).

Разберем алгоритм действий:

1. Выясним внутренний идентификатор документа. Для этого откроем файл 1SJOURN.dbf и найдем строку по номеру документа (поле DOCNO) и дате (поле DATE_TIME).
2. Запомним значение в поле IDDOC (это 9-значный код в 36-ричной системе).
3. Найдем в этой же таблице дублирующую запись. Скорее всего, вы обнаружите две строки с одинаковым IDDOC или строку, данные которой не соответствуют визуальным данным из журнала.
4. Удалим проблемные строки непосредственно из 1SJOURN.dbf. Обратите внимание, что в DBF физическое удаление происходит только после упаковки (Pack), а до этого запись помечается как удаленная (символ «*»).
5. Далее необходимо найти соответствующие записи в таблицах DHxxxx.dbf и DTxxxx.dbf по тому же идентификатору IDDOC и также удалить их.
6. После ручной правки обязательно удалим все .cdx файлы и запустим переиндексацию.

Способ 3. Штатное «Тестирование и исправление»

Проанализируем стандартные возможности платформы. Иногда достаточно глубокого тестирования, чтобы система сама вычистила логические несоответствия.

Рассмотрим порядок действий в Конфигураторе:

1. Перейдем в меню «Администрирование» — «Тестирование и исправление ИБ».
2. Установим следующие флажки:
   • Реиндексация таблиц: Полная перестройка индексов.
   • Проверка целостности данных: Поможет выявить ссылки, ведущие «в никуда».
   • Проверка ссылочной целостности: Позволит обработать объекты, у которых нет владельца или основной записи.
   • Упаковка таблиц: Физически удалит из файлов записи, помеченные на удаление (именно это помогает убрать «призраков», которые не видны, но мешают).
3. В поле «При наличии ссылок на несуществующие объекты» выберем «Очищать ссылки» или «Создавать объекты» (второй вариант позволит увидеть, что именно потерялось).

Важное замечание: Не запускайте тестирование сразу на рабочей базе. Если структура сильно повреждена, 1С может необратимо удалить данные. Сначала выполните процедуру на копии и проверьте результат.

Способ 4. Логическое пересоздание документа

Если технических навыков для правки DBF недостаточно, можно пойти по пути наименьшего сопротивления. Попробуем создать новый «чистый» документ.

Рассмотрим шаги:

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

Как предотвратить появление дублей в будущем?

Выясним, какие профилактические меры помогут избежать подобных сбоев:

• Проверка префиксов УРБД: Убедитесь, что в каждой периферийной базе установлен уникальный трехсимвольный префикс в настройках обмена. Это гарантирует уникальность IDDOC.
• Контроль размера базы: Если файл 1SJOURN.dbf превышает 1 ГБ, пора задуматься о свертке базы или переходе на версию 1С 7.7 для SQL.
• Исключение антивирусной блокировки: Добавьте расширения .dbf и .cdx в исключения антивируса на сервере и рабочих станциях. Часто именно блокировка файла антивирусом в момент записи приводит к частичному сохранению документа.
• Регулярная профилактика: Раз в месяц выполняйте переиндексацию и упаковку таблиц во внерабочее время.

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