Ситуация, когда в базе данных 1С появляются «битые ссылки» (записи вида <Объект не найден...>), является одной из самых неприятных для администратора или программиста. Особенно остро эта проблема проявляется в конфигурации «Управление торговлей 11», где справочники Партнеры и Контрагенты тесно взаимосвязаны. В этой статье мы подробно разберем, почему возникают такие «записи-сироты», почему стандартные средства тестирования и исправления часто бессильны и как восстановить целостность данных без потери истории документов.
Прежде всего, нам необходимо понять архитектурную особенность УТ 11. В данной конфигурации разделены понятия управленческого учета (Партнеры) и регламентированного учета (Контрагенты). Между ними существует связь, которая может быть как «один к одному», так и «один ко многим» (в случае холдинговых структур).
Когда пользователь выполняет интерактивное удаление, он может удалить запись в одном справочнике (например, Контрагенты), в то время как в другом справочнике (Партнеры) или в связанных регистрах сведений (например, Соответствия объектов информационных баз или Публичные идентификаторы объектов) информация сохраняется. Разберем по шагам, почему это приводит к «дичи» в интерфейсе:
Рассмотрим ситуацию, когда стандартная процедура Тестирование и исправление (ТиИ) не дает результата. Это происходит потому, что ТиИ проверяет ссылочную целостность: если на объект есть ссылки в документах, программа предложит его восстановить или очистить ссылки. Однако, если объект «завис» в динамических списках или кэше индексов, ТиИ может не обнаружить логической ошибки.
Утилита chdbfl.exe также бесполезна в этом случае, так как она проверяет физическую структуру файла базы данных (таблицы, страницы, заголовки), но не занимается логическими связями между бизнес-объектами 1С. Для нее отсутствие строки в таблице — это не ошибка, если структура самой таблицы не нарушена.
Проанализируем метод, который помог автору темы. Часто стандартная форма списка или карточка элемента скрывает реальное положение дел. Динамический список может отображать данные из закэшированных таблиц или связанных регистров.
Рекомендуется воспользоваться обработкой «Универсальный редактор реквизитов» или аналогичными инструментами (например, из состава «Инструментов разработчика»).
Партнеры, и Контрагенты).УстановитьПометкуУдаления()), что зачастую срабатывает там, где бессилен интерфейс.Выясним, как восстановить объект так, чтобы все старые документы «узнали» его. Самый надежный способ — создать новый элемент справочника и присвоить ему тот самый GUID, который остался в битой ссылке.
Рассмотрим пример кода, который позволяет это сделать. Для начала нам нужно получить уникальный идентификатор из битой ссылки (ее можно взять из любого документа, где она отображается):
// Предположим, у нас есть строка с GUID битой ссылки
СтрокаGUID = "550e8400-e29b-41d4-a716-446655440000";
НужныйGUID = Новый УникальныйИдентификатор(СтрокаGUID);
// Создаем ссылку на основе GUID
НоваяСсылка = Справочники.Контрагенты.ПолучитьСсылку(НужныйGUID);
// Пытаемся создать объект
НовыйОбъект = Справочники.Контрагенты.СоздатьЭлемент();
НовыйОбъект.УстановитьСсылкуНового(НоваяСсылка);
// Заполняем обязательные реквизиты
НовыйОбъект.Наименование = "Восстановленный Континент";
НовыйОбъект.ИНН = "1234567890";
НовыйОбъект.КПП = "123456001";
Попытка
НовыйОбъект.Записать();
Сообщить("Объект успешно восстановлен с прежним GUID");
Исключение
Сообщить("Ошибка при записи: " + ОписаниеОшибки());
КонецПопытки;
Метод УстановитьСсылкуНового() — это ключевой инструмент. Он позволяет принудительно назначить объекту нужный идентификатор до его первой записи в базу данных. После этого все документы, которые ранее показывали <Объект не найден...>, сразу начнут отображать имя этого контрагента.
Если при попытке записи восстановленного объекта система продолжает ругаться на дубль ИНН, хотя визуально в справочнике такой записи нет, проанализируем следующие шаги:
НСИ и администрирование -> Настройка НСИ и разделов -> CRM и маркетинг) проверку уникальности партнеров по ИНН/КПП. Это позволит записать объект, после чего можно будет провести его «слияние» со старой битой ссылкой.Администрирование -> Поддержка и обслуживание -> Полнотекстовый поиск).В исключительных случаях, когда запись видна в списках, но к ней невозможно обратиться программно из 1С, проблема может заключаться в рассогласовании индексов SQL и таблиц 1С. Посмотрим, как это выглядит на уровне базы данных:
_ReferenceX._ReferenceX отсутствует строка с конкретным _IDRRef, но этот _IDRRef присутствует в таблицах документов (например, _DocumentY).DBCC CHECKDB после манипуляций, чтобы убедиться в целостности базы.Однако лучшим решением всегда остается использование программных методов 1С, так как они гарантируют соблюдение бизнес-логики и правильное обновление индексов самой платформы.
Мы разобрали сложную проблему «записей-сирот». Подведем итог алгоритму действий:
Партнеры или Контрагенты).УстановитьСсылкуНового().Соблюдение этого порядка действий позволит вам «вылечить» базу данных без радикальных мер вроде отката на копию двухдневной давности.