← На главную

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

Устройство внутренних идентификаторов в 1С 7.7

Проанализируем структуру хранения ссылок в файловом формате DBF. Каждый элемент справочника, документ или строка имеют внутренний идентификатор (поле ID в таблицах SC*.DBF, поле IDDOC в журнале 1SJOURN.DBF):

1. Система счисления Base-36: Идентификаторы генерируются с использованием цифр 0-9 и латинских букв A-Z. Для программного преобразования между десятичным числом и строковым представлением платформа использует встроенные функции _IdToStr() и _StrToId().
2. Длина поля: Для локальных справочников длина поля составляет 4 символа (значения дополняются пробелами слева). В распределенных базах (УРБД) к идентификатору добавляется трехсимвольный префикс узла информационной базы.
3. Контроль уникальности: За автогенерацию новых значений отвечает системная таблица 1SUIDCTL.DBF и индексы таблиц. Если в файловом режиме при сбое индексных файлов *.CDX база может продолжать работать с задвоенным ID, то при конвертации в SQL накладываются жесткие ограничения первичного ключа (PRIMARY KEY), что приводит к сбою загрузки.

Подготовительный этап: сохранение данных и анализ аналитики

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

Выясним причину, почему нельзя просто отредактировать ID в DBF-редакторе на случайное значение:

1. Если элемент справочника уже использовался в хозяйственных операциях, его старый ID записан в таблицах шапок (DH*.DBF) и табличных частей документов (DT*.DBF), в движениях и итогах регистров (RA*.DBF, RG*.DBF), а также в периодических реквизитах (1SCONST.DBF).
2. При наличии двух элементов с одинаковым ID встроенные отчеты платформы объединяют движения обоих объектов или отображают только первый найденный по индексу элемент.
3. Сформируем отчеты по товародвижению (или движению соответствующих сущностей) за весь период работы базы, чтобы оценить реальный объем движений по задублированной позиции.

Способ 1. Программная замена ссылок (рекомендуемый способ)

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

1. Открываем базу в режиме 1С:Предприятие.
2. Создаем новый элемент справочника с требуемым наименованием и реквизитами. Платформа автоматически выделит ему гарантированно уникальный внутренний ID в Base-36.
3. С помощью специализированной обработки поиска и замены значений (например, типовой обработки ПоискИЗаменаЗначений или ReplVal.ert) производим поиск всех ссылок на дублирующий элемент и перенаправляем их на вновь созданную позицию.
4. Помечаем проблемный элемент на удаление и удаляем его штатным механизмом «Удаление помеченных объектов».

Способ 2. Ручная корректировка DBF-файла справочника

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

1. Определяем имя файла справочника по словарю данных конфигурации 1CV7.DD (например, справочнику «Продукция» соответствует таблица SC123.DBF).
2. Закрываем конфигуратор и предприятие, открываем нужный SC*.DBF в DBF-редакторе.
3. Находим записи с дублирующимся значением в поле ID.
4. Если дубль не нужен, помечаем запись на удаление и обязательно выполняем процедуру сжатия/упаковки таблицы (операция PACK), чтобы удалить байты записи физически.
5. Если требуется сохранить обе записи с разными кодами, вычисляем максимальный существующий идентификатор в таблице, прибавляем единицу в 36-ричной системе счисления и прописываем новое значение в поле ID (помня о необходимости выравнивания пробелами).
6. Критически важный шаг: после закрытия DBF-редактора удаляем все индексные файлы *.CDX в каталоге базы данных. При следующем входе в программу 1С перестроит индексы заново.

Устранение ошибки «Нет ответной заголовочной части» в журнале документов

При ручной очистке данных или сбоях в процессе тестирования базы может возникнуть сопутствующая ошибка: «Проверка таблицы журнала документов. Запись N. Нет ответной заголовочной части». Разберем по шагам механизм ее исправления:

1. Анализ структуры: Каждому документу соответствует общая запись в журнале 1SJOURN.DBF и отдельная запись шапки в таблице DH<IDDOCDEF>.DBF, где <IDDOCDEF> — внутренний номер вида документа. Ошибка означает, что запись в 1SJOURN существует, но в таблице DH* документ с соответствующим IDDOC отсутствует.
2. Открываем файл 1SJOURN.DBF, переходим к записи с номером, указанным в сообщении об ошибке, и считываем значение полей IDDOC и IDDOCDEF.
3. По коду IDDOCDEF в файле 1CV7.DD определяем вид документа и имя таблицы шапки DH*.DBF.
4. Если документ является «фантомным» и не нужен для учета, удаляем запись с данным IDDOC из 1SJOURN.DBF (а также связанные строки из 1SCRDOC.DBF и DT*.DBF при их наличии), после чего упаковываем таблицы (PACK).
5. Если документ необходим, восстанавливаем строку с соответствующим IDDOC в целевой таблице DH*.DBF.
6. Удаляем файлы *.CDX для запуска полной переиндексации базы данных и повторно запускаем тестирование и исправление.