Ситуация, когда при попытке загрузить информационную базу из файла выгрузки .dt возникает ошибка неуникальности записей, является одной из самых сложных в практике администрирования 1С. Часто это происходит при миграции с файлового варианта на клиент-серверный, когда база в файловом режиме уже работает нестабильно из-за превышения лимитов размера таблиц. Рассмотрим подробно, почему возникает эта проблема и какими методами ее можно решить.
Первым делом проанализируем, почему 1С вообще позволяет выгрузить «битые» данные в .dt, которые потом не загружаются. Основные причины следующие:
.1CD) механизмы контроля целостности менее строгие, чем в SQL-версиях. Если база достигла критического размера (4 ГБ на таблицу), индексы могут начать работать некорректно, допуская появление дублей.Как показывает практика и обсуждение, часто проблема решается простым обновлением или, наоборот, откатом версии технологической платформы. Разберем этот алгоритм:
Попробуем загрузить базу на самых свежих релизах веток 8.3.20 или выше. Если это не помогает, стоит протестировать «классические» стабильные версии. В сообщениях форума упоминается, что критические ошибки были исправлены в следующих версиях: 8.3.15.1985, 8.3.16.1502, 8.3.17.1496, 8.3.18.1128, 8.3.19.1150.
Проанализируем дату создания вашего .dt. Если вы знаете, на какой версии он выгружался, постарайтесь использовать именно её для загрузки. Если же версия неизвестна, рекомендуется попробовать «всеядную» версию 8.3.8.2137 (она часто справляется там, где новые версии слишком строго проверяют структуру индексов).
При загрузке на сервер (MS SQL или PostgreSQL) крайне важно исключить влияние внешних факторов. Выполним следующие действия:
Если загрузка все равно прерывается, нам нужно точно понять, в какой таблице находятся дубли. Рассмотрим процесс для MS SQL Server:
Запустим инструмент SQL Server Profiler. Настроим трассировку на событие RPC:Completed и Exception. Запустим загрузку .dt в 1С. В момент возникновения ошибки Profiler зафиксирует последний SQL-запрос INSERT INTO. Имя таблицы в запросе будет иметь вид _InfoReg1234 или _Document567.
Чтобы понять, какому объекту 1С соответствует эта таблица, выполним запрос к базе данных (если она успела частично создаться):
SELECT * FROM CAST(Config AS XML).nodes('/Metadata/Table') AS T(C)
WHERE T.C.value('@name', 'nvarchar(max)') = '_InfoReg1234'
Либо воспользуемся стандартной обработкой «Просмотр структуры выбранной базы данных» из состава ИТС. Зная имя регистра или справочника, мы поймем, какими данными можно пожертвовать.
Разберем продвинутый метод «лечения», если у вас есть доступ к SQL-серверу:
IGNORE_DUP_KEY = ON. Внимание: это радикальный метод, который может привести к потере части данных (дубли просто не запишутся).GROUP BY ... HAVING COUNT(*) > 1 и удалить лишние вручную.Если вы столкнулись с ошибкой размера таблиц в файловой версии, это означает, что объем данных в одной из таблиц (вместе с индексами) превысил 4 ГБ. Даже если вы успешно загрузите такой .dt на сервер, при попытке выгрузить его обратно в файловый вариант вы снова получите ошибку.
Проанализируем ситуацию: чаще всего «раздуваются» такие таблицы как _JobHistory (история заданий), _InfoReg... (версии объектов или журнал регистрации). После загрузки на сервер выполните очистку этих таблиц. Для этого в 1С используйте типовые обработки «Очистка ненужных файлов» или «Свертка информационной базы».
Рассмотрим вариант, когда стандартные средства бессильны. Существуют утилиты для низкоуровневой работы с файлами 1С. Хотя DTManager изначально разрабатывался для версии 8.1, для версии 8.3 существуют альтернативные скрипты на Python или обработки типа V8Reader. Они позволяют «распаковать» .dt как архив, найти внутри файлы данных и попытаться вручную удалить битые записи из текстовых дампов. Это крайне трудоемкий процесс, который требует глубоких знаний структуры формата .dt, но иногда это единственный способ спасти данные, если файл .1CD безвозвратно утерян.
Резюмируем: наиболее эффективный путь — использование платформы версии 8.3.8.2137 для разовой загрузки на MS SQL Server, последующая идентификация таблицы с дублями через Profiler и её очистка методами 1С.