В процессе эксплуатации информационных баз «1С:Предприятие 8» администраторы и разработчики иногда сталкиваются с неприятными ошибками при проверке логической целостности. Одной из наиболее трудноустранимых стандартными средствами является ошибка вида: «Проверка логической целостности. Документы... Табличная часть имеет записи, не относящиеся ни к одной записи главной таблицы». Часто эта проблема сопровождается невозможностью выгрузить базу данных в формат .dt из-за ошибок в таблице служебных файлов Files.
В этой статье мы подробно разберем, почему возникают эти ошибки, как локализовать проблему и какими способами — как в файловом варианте, так и на сервере SQL — вернуть базу данных в полностью рабочее состояние.
В реляционных базах данных связь между главной таблицей (шапкой документа или справочника) и его табличной частью организуется по уникальному идентификатору родительского объекта (в СУБД это поле называется _IDRRef или аналогично в зависимости от структуры). Если во время записи документа, проведения транзакции или при аппаратном сбое (например, отключении питания сервера) процесс прерывается, может возникнуть рассинхронизация. Физически строки табличной части записываются в базу данных, а сам документ-родитель — нет. В итоге в базе появляются так называемые «осиротевшие» строки табличной части.
Стандартное Тестирование и исправление (ТиИ) силами конфигуратора 1С далеко не всегда способно автоматически удалить или привязать такие строки, особенно если повреждена структура самих таблиц или в базе присутствуют ошибки в служебной таблице Files.
---
Если ваша база данных работает под управлением MS SQL Server или вы можете временно загрузить файловую базу (.dt-файл) на SQL-сервер для проведения технических работ, то этот метод является самым быстрым и надежным.
Рассмотрим по шагам, как локализовать и удалить битые строки табличной части.
Шаг 1. Определение имени таблицы в СУБД
Для начала нам нужно сопоставить понятное имя документа 1С (например, ПоступлениеТоваровУслуг) с физическим именем таблицы в SQL. Для этого можно воспользоваться программными методами 1С (например, функцией ПолучитьСтруктуруХраненияБазыДанных()) или сторонними обработками. Предположим, что главная таблица документа имеет имя _Document196, а табличная часть — _Document196_VT4169.
Шаг 2. Поиск «осиротевших» записей
Выполним SQL-запрос типа LEFT JOIN, чтобы найти строки табличной части, у которых нет соответствия в главной таблице документов. Проанализируем следующую выборку:
SELECT vt.*
FROM _Document196_VT4169 vt
LEFT JOIN _Document196 doc ON vt._Document196_IDRRef = doc._IDRRef
WHERE doc._IDRRef IS NULL;
Если этот запрос возвращает строки, значит, мы нашли именно те лишние записи, из-за которых платформа выдает ошибку логической целостности.
Шаг 3. Удаление лишних строк
После того как мы убедились, что запрос выбрал именно некорректные записи, мы можем безопасно удалить их из табличной части, выполнив следующий запрос:
DELETE vt
FROM _Document196_VT4169 vt
LEFT JOIN _Document196 doc ON vt._Document196_IDRRef = doc._IDRRef
WHERE doc._IDRRef IS NULL;
После выполнения этой операции и повторного запуска проверки логической целостности в Конфигураторе ошибка по данному документу исчезнет.
---
Если база данных работает в файловом режиме и у вас нет возможности или желания переносить ее на SQL-сервер, проблему можно решить с помощью специализированных обработок внутри самой системы 1С.
Разберем алгоритм восстановления связей:
8ca0d017-c29a-ac75-11e6-e6bb9148a258), мы можем воссоздать родительский документ.GUID (например, GUID82_w1c.epf).
НовыйДок = Документы.ПоступлениеТоваровУслуг.СоздатьДокумент();
НовыйДок.УстановитьСсылкуНового(Документы.ПоступлениеТоваровУслуг.ПолучитьСсылку(Новый УникальныйИдентификатор("8ca0d017-c29a-ac75-11e6-e6bb9148a258")));
НовыйДок.Дата = ТекущаяДата(); // или примерная дата из движений
НовыйДок.Записать();
После записи нового документа с данным GUID осиротевшая табличная часть автоматически привяжется к нему. Вам останется лишь зайти в созданный документ, заполнить недостающие реквизиты шапки (контрагент, договор и т.д.) и провести его.
Также при запуске стандартного Тестирования и исправления (ТиИ) обязательно выбирайте режим «При наличии ссылок на несуществующие объекты: Создавать объекты (или Добавлять)». В этом случае платформа попытается самостоятельно создать пустые документы-заглушки для осиротевших табличных частей. Если требуется проводить обслуживание нескольких систем, процедуру можно запустить через инструмент для автоматического тестирования и архивации баз 1С в тихом режиме.
---
Часто параллельно с логической ошибкой табличных частей возникает сбой при попытке выгрузить базу данных в .dt. Платформа выдает ошибку вида: «Нарушение целостности информационной базы. Ошибка в размере файла ... pfl при выгрузке таблицы Files. Ожидаемое значение 0, значение в таблице 112163».
Файлы настроек пользователя с расширением .pfl хранятся в бинарном виде в таблице Files. Из-за ошибок платформы размер, записанный в поле описания данных (DATASIZE), перестает соответствовать реальному физическому размеру данных. Утилита chdbfl.exe эту ошибку обычно игнорирует.
Способ исправления в MS SQL:
Если база на SQL-сервере, достаточно просто очистить запись о поврежденном файле настроек. При следующем входе пользователя система автоматически создаст этот файл заново с нулевым или корректным размером. Выполните следующий запрос:
DELETE FROM Files
WHERE FileName = '1d748980-248d-4f48-a467-23fe2d86ab01.pfl';
Способ исправления в файловой базе через Tool1CD:
Если база файловая, используйте специализированную утилиту для просмотра и редактирования файлов баз данных 1С — Tool1CD (версии, поддерживающие редактирование, например, Tool1CD_mod):
1Cv8.1CD в утилите.FILES.FILENAME, которая совпадает с именем поврежденного файла из текста ошибки (например, 1d748980-248d-4f48-a467-23fe2d86ab01.pfl).DATASIZE на 0 (или на то значение, которое система указывает в качестве ожидаемого).После этой процедуры выгрузка информационной базы в файл .dt пройдет без ошибок.
---
Иногда при переносе файловой базы на MS SQL для выполнения ремонтных работ администраторы сталкиваются с неожиданной ошибкой запуска Конфигуратора: «Ошибка программного лицензирования. Неверный формат файла программного лицензирования File=src\CryptoGeneralHelpers.cpp(207)».
Выясним причину этой проблемы. При смене режима работы с файлового на клиент-серверный платформа 1С кардинально меняет логику проверки лицензий. Ошибка модуля криптографии чаще всего свидетельствует о наличии поврежденного кэша лицензий или использовании неофициальных эмуляторов защиты, которые блокируют работу сервера приложений.
Для устранения этой проблемы выполните следующие действия:
C:\ProgramData\1C\licenses и %userprofile%\AppData\Local\1C\1Cv8\conf.Выполнение этих шагов позволит вам успешно запустить конфигуратор в режиме СУБД, завершить исправление логической структуры базы данных и вернуть ее обратно в работу.