Как устроены ссылочные связи между объектами 1С и что делать, когда они рвутся

Ключ связи в 1С — это значение, по которому одна запись базы находит другую. Чаще всего это ссылка: 16-байтный уникальный идентификатор (GUID) объекта, который записан в реквизит другого объекта. Документ «Реализация» хранит не название контрагента, а его идентификатор. Если запись с таким идентификатором пропала, в поле появляется <Объект не найден> (85:b4d3a1...). Исправляют это в Конфигураторе: Администрирование → Тестирование и исправление с проверкой ссылочной целостности.

Ошибки ключей связи находят тремя способами. Запрос 1С подходит пользователю с правами администратора и ничего не ломает. SQL-запрос к таблицам СУБД нужен, когда база большая и тестирование идёт часами. Тестирование и исправление — единственный штатный способ не только найти, но и починить разрыв.

Как ключ связи хранится в базе 1С

В 1С:Предприятии 8.3 у каждого ссылочного объекта есть внутренний идентификатор. Это справочники, документы, планы видов характеристик, планы счетов, бизнес-процессы, задачи. Идентификатор генерируется при первой записи объекта и больше не меняется. Код, номер и наименование можно переписать, а ссылка остаётся прежней.

В таблицах СУБД это выглядит так:

• 🗂 таблица справочника называется вроде _Reference23, документа — _Document45;
• 🔑 первичный ключ — поле _IDRRef типа binary(16) в MS SQL или bytea в PostgreSQL;
• 🔗 реквизит ссылочного типа — поле _Fld1234RRef, в нём лежит тот же 16-байтный идентификатор;
• 🧩 реквизит составного типа раскладывается на несколько полей: _Fld1234_TYPE (вид значения), _Fld1234_RTRef (код таблицы, на которую ссылка) и _Fld1234_RRRef (сам идентификатор), плюс отдельные поля для чисел, строк и дат.

Пустая ссылка хранится как шестнадцать нулевых байт 0x00000000000000000000000000000000. Это не ошибка, а нормальное «реквизит не заполнен».

Важная деталь: платформа не создаёт в СУБД внешних ключей (foreign key). Ничто на уровне SQL Server или PostgreSQL не мешает удалить справочник, на который ссылаются документы. Целостность связей держит сама платформа, поэтому любое обходное удаление оставляет «висячие» ссылки.

Как сопоставить GUID и поле _IDRRef

GUID, который показывает 1С (ВРег(Строка(Ссылка.УникальныйИдентификатор()))), и байты в _IDRRef записаны в разном порядке. Для GUID вида AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE в поле лежит 0xDDDDEEEEEEEEEEEECCCCBBBBAAAAAAAA. Это пригодится, когда ищете конкретную запись в SQL по идентификатору из 1С.

Имена таблиц и полей для своей конфигурации смотрите методом ПолучитьСтруктуруХраненияБазыДанных(). Его вызывают из внешней обработки или консоли кода: метод возвращает таблицу соответствия «объект метаданных → таблица СУБД → поля». Номера вида _Reference23 у каждой базы свои, переносить их из чужих примеров нельзя.

Другие значения термина

Словом «ключ связи» называют ещё две вещи, и их полезно не путать с ссылками:

• 📑 в некоторых типовых конфигурациях у табличных частей есть числовой реквизит КлючСвязи или КлючСтроки. Им строка подчинённой табличной части привязана к строке основной (например, серии к строке товаров). Если такую строку удалить обработкой мимо формы, «хвост» остаётся без пары;
• 🧮 в конструкторе запроса и в схеме компоновки данных связь между таблицами задаётся условием на вкладке «Связи». Там ключ связи — поля, по которым соединяются источники.

Дальше речь о ссылочных связях: именно они ломаются чаще всего и дают ошибки при работе.

Откуда в базе берутся битые ссылки

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

• 🗑 Удаление без контроля ссылок. Объект удалили непосредственно (не пометкой) из кода, через обработку или с отключённой проверкой. Ссылки на него в документах остались.
• 🔄 Обмен данными. Документ пришёл из другой базы, а справочник, на который он ссылается, не выгрузили. Платформа создаёт запись с пустыми данными или оставляет ссылку без объекта, в зависимости от правил обмена.
• 📦 Частичный перенос. Загрузили часть данных через .xml, «Выгрузку и загрузку данных XML» или свою обработку без связанных справочников.
• 💥 Аварийное завершение. Отключение питания или падение рабочего процесса во время записи. В файловой базе после этого страдает сам файл 1Cv8.1CD.
• 🛠 Прямая правка таблиц СУБД. Кто-то удалил или поправил строки в SQL мимо платформы.
• 🧱 Изменение конфигурации. Удалили справочник или реквизит, а данные в регистрах остались со старым типом.

Отдельный случай — объекты с пустыми данными. После загрузки обмена в списке справочника появляется элемент без наименования и кода. Формально ссылка цела, но смысла в записи нет.

Признаки разрыва связи

Битые ссылки редко заметны сразу. Чаще их находят по косвенным признакам:

Поиск битых ссылок запросом и SQL

Начинайте с запроса 1С. Он работает через платформу, учитывает права и не трогает данные. SQL нужен, когда таблиц сотни, а объём — десятки гигабайт.

Запрос 1С: проверка через разыменование

Приём простой: если ссылка не пустая, а обращение к её полю .Ссылка даёт NULL, объекта нет. Пример для реквизита Контрагент документа «Реализация товаров и услуг»:

ВЫБРАТЬ
	Док.Ссылка КАК Документ,
	Док.Контрагент КАК БитаяСсылка
ИЗ
	Документ.РеализацияТоваровУслуг КАК Док
ГДЕ
	Док.Контрагент <> ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка)
	И Док.Контрагент.Ссылка ЕСТЬ NULL

Запрос выполняют в «Консоли запросов» (внешняя обработка) от пользователя с полными правами. Для реквизита составного типа добавьте условие на тип: ТИПЗНАЧЕНИЯ(Док.Субконто1) = ТИП(Справочник.Номенклатура), иначе пустые значения других типов попадут в выборку.

Для регистров то же самое: таблица РегистрНакопления.ТоварыНаСкладах, условие на нужное измерение. В бухгалтерских конфигурациях проверяйте субконто в РегистрБухгалтерии.Хозрасчетный, там битые ссылки встречаются часто.

SQL: прямое чтение таблиц

В клиент-серверной базе тот же поиск можно сделать в SQL Server Management Studio или psql. Имена таблиц и полей берите из ПолучитьСтруктуруХраненияБазыДанных(). Пример для MS SQL:

SELECT d._IDRRef, d._Fld1234RRef
FROM _Document45 AS d
LEFT JOIN _Reference23 AS r
       ON r._IDRRef = d._Fld1234RRef
WHERE d._Fld1234RRef <> 0x00000000000000000000000000000000
  AND r._IDRRef IS NULL;

Для PostgreSQL условие пустой ссылки пишется как d._fld1234rref <> '\x00000000000000000000000000000000'::bytea, имена таблиц и полей — в нижнем регистре.

Сколько всего ссылок на конкретный объект, можно посчитать из 1С методом НайтиПоСсылкам(). Он перебирает все таблицы и на большой базе работает долго, но точно.

Как починить связи: от мягкого к радикальному

Перед любым исправлением сделайте выгрузку в .dt или резервную копию средствами СУБД. Режимы исправления меняют данные необратимо.

Тестирование и исправление в Конфигураторе

Режим требует монопольного доступа. Предупредите пользователей: все сеансы нужно завершить.

1. Откройте базу в Конфигураторе.
2. Выберите Администрирование → Тестирование и исправление.
3. Отметьте «Проверка логической целостности информационной базы» и «Проверка ссылочной целостности информационной базы».
4. Для первого прогона выберите режим «Только тестирование». Посмотрите отчёт: сколько ссылок битых и в каких объектах.
5. Если всё понятно, повторите в режиме «Тестирование и исправление». Для ссылок на несуществующие объекты выберите «Создавать объекты» или «Очищать ссылки».
6. После исправления запустите «Пересчёт итогов».
7. Перепроведите документы, где были разрывы, или закройте месяц заново.

💡 Режим «Создавать объекты» безопаснее для учёта. Платформа создаёт пустые элементы с потерянными идентификаторами, и все связи сохраняются. Потом их можно заполнить реквизитами или заменить на правильные через «Поиск и замену значений».

Запуск из командной строки

Ту же проверку можно запустить без интерфейса, например ночью:

"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /P"" /IBCheckAndRepair -LogIntegrity -LogAndRefsIntegrity -BadRefCreate /Out"D:\Logs\tii.log"

Номер платформы в пути замените на свой. Ключ -TestOnly включает только тестирование без исправления, -BadRefClear очищает ссылки вместо создания объектов, -RecalcTotals добавляет пересчёт итогов. Для серверной базы вместо /F укажите /S"сервер\имябазы".

Как не допускать разрывов: регламент обслуживания

Битые ссылки проще не создавать, чем искать. Несколько правил закрывают большинство причин.

• 🏷 Удаляйте только через пометку. В типовых конфигурациях на БСП есть обработка «Удаление помеченных объектов» в разделе Администрирование → Обслуживание. Она проверяет, используется ли объект, и не даёт удалить то, на что есть ссылки. Там же можно включить автоматическое удаление по расписанию.
• 🔐 Заберите право «Интерактивное удаление» у пользователей. В типовых ролях его и так нет, но в доработанных конфигурациях встречается.
• 🔄 Проверяйте правила обмена. Связанные справочники должны выгружаться вместе с документами. После первой синхронизации проверьте базу-приёмник запросом из раздела выше.
• 🖥 Ставьте ИБП на сервер или компьютер с файловой базой. Обрыв записи — главная причина физических повреждений.
• 📅 Планируйте проверку. Тестирование и исправление штатно не запускается регламентным заданием внутри 1С. Его ставят в планировщик Windows командой из раздела выше, на время, когда в базе никто не работает .

Для клиент-серверной базы регламент живёт в СУБД. В MS SQL — план обслуживания: проверка DBCC CHECKDB, перестроение индексов, обновление статистики, резервное копирование . В PostgreSQL — VACUUM ANALYZE по расписанию и проверка индексов расширением amcheck.

Файловая и клиент-серверная база: в чём разница

Ссылки хранятся одинаково, а вот инструменты проверки различаются.

Особенности файловой базы

Файл 1Cv8.1CD повреждается при сбоях сети и питания. Если база не открывается или ТиИ падает с ошибкой, начинайте с chkdbfl.exe. Утилита лежит в каталоге bin установленной платформы и запускается при закрытой базе.

Сначала нажмите «Выполнить» без галочки «Исправлять обнаруженные ошибки». Если ошибки есть — скопируйте файл базы целиком и только потом запустите исправление на копии. После chkdbfl обязательно прогоните ТиИ: утилита чинит структуру файла, а не связи между объектами.

Особенности клиент-серверной базы

На большой серверной базе полное ТиИ может идти несколько часов. Поэтому порядок другой: сначала SQL-запросами найдите, где разрывы, потом решите, нужно ли полное ТиИ.

Если ТиИ прерывается с ошибкой СУБД, проблема физическая. Сначала DBCC CHECKDB (или проверка в PostgreSQL), потом повтор ТиИ.

Частые вопросы