Всем привет.
Есть dt-файл УТ 11.1.10.131

При загрузке dt-файла в новую базу SQL вываливается ошибка:

Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 11.0: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем "dbo._AccumRgT17414" и индекса с именем "_Accum17414_ByDims_TRRRRSTN". Повторяющееся значение ключа: (0, окт  1 4015 12:00AM, 0x8574f39fb4b79b1f41c6c6a0f957ed56, 0x98a6001e676ecaa611e2cbacf025db1c, 0xa80e001e679db8f411e496bfe2f9edc8, 0x86eb001e679db8f411e4e99a5b1797f3, 1111                  , сен 12 4015 12:00AM, 0).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1

В SQL новичок.

Версия SQL 2014: 12.0.4213.0
ОС: Windows Server 2012 R2

Что пробовал:
Разворачивал dt-файл в файловую базу.
Выполнил проверку файла 1CD утилитой chbdfl.exe без ошибок.
Выполнил полное ТИИ.

Вопрос:
1. Как исправить?
2. Возможно ли в SQL включить такой режим, который будет игнорировать подобные ошибки?
Думаю этот режим позволит мне загрузить базу в SQL и средствами SQL поправить найденные ошибки.

Мой Skype:geraskindenis
ICQ:285911490

Нужна ваша помощь!!!

а знаю... не хватает версии 1С платформы.
1С 8.3.6.2332

в файловой для начала полное ТИИ. Потом уже выгружай

мне пока показалась подозрительной дата..
окт  1 4015 12:00AM

аа, смещение 2000 же!

(2) так и сделал

(5)а прогу что в Bin  лежит запускал?

(6)Выполнил проверку файла 1CD утилитой chbdfl.exe без ошибок.

(7) тогда надо понять что такое dbo._AccumRgT17414 в файловой базе. открыть ее и вычистить все что мешает правильной загрузке.

(8) можно обработкой просмотра метаданных найти этот индекс в конфе и удалить, и поставить снова, после этого перевыгрузить

(7) Видно по идентификатору, что это по регистру накопления. Какой именно - смотреть по метаданным.

Полное ТИИ имеется ввиду, что Сжатие таблиц и Реиндексация, и Сжатие Таблиц, и Реструктуризация Таблиц были выполнены?

Есть вероятность, что регистр не типовой и там установлена какая-то не пойми зачем нужная комбинация флагов на измерениях и реквизитах регистра. Тогда убрать пометки на эти индексы из реквизитов регистра, обновить базу и попытаться снова перейти на SQL

после загрузки в SQL можете отдельно протестировать использование этих индексов - это уже будет более уместно, т.к. использование другого движка базы может давать отличные от прежних значения индексов.

Распроведи все документы за 12 сентября, выгрузи в dt, загрузи в SQL, потом проведи

А вот "окт  1 4015" - это таблица итогов. Пересчет итогов всех регистров сделай через ИР

(10) Полное ТИИ - да, и сжатие и реструктуризация и реиндексация
(11) при загрузке в SQL вываливается ошибка
(12) спасибо за идею
(13) спасибо, сделаю

(12) Кстати, да. Но тут все-таки желательно убедиться в том, что или конфигурация полностью типовая, или там нет никаких самописных извращений в собственно метаданных с регистрами накопления

(14) // при загрузке в SQL вываливается ошибка
угу. я и предлагаю на крайний случай отключить индексы у этого регистра напрочь и включить их обратно уже после загрузки. Но самое простое, как в (12) - просто снять с проведения регистраторы перед выгрузкой ДТ и провести их уже в SQL

(14) только обязательно через ИР, т.к. у меня через штатную пересчитывалку не взлетело, а после ИР - взлетело

(12) (13) +1
Еще один вариант обхода:
1. Отключить у проблемного регистра накопления AccumRgT17414 использование итогов и текущих итогов. Если не знаешь о каком регистре идет речь можно отключить итоги тупо у всех регистров.
2. Выгрузить в dt
3. Загрузить в SQL
4. В базе на SQL включить использование итогов и текущих итогов у регистра(ов), где отключали итоги на первом шаге.

А вообще косяк в движениях регистра за 12 сентября. Где-то есть запись с пустыми или некорректно заполненными измерениями. Например в измерение Номенклатура запихнули значение НЕ из справочника Номенклатура или вообще пустое значение не смотря на запрет незаполненных значений. При записи набора в режиме ОбменДанными.Загрузка=Истина такое может проскочить.

". Возможно ли в SQL включить такой режим, который будет игнорировать подобные ошибки?"

возможно

для этого надо написать Ddl триггер , отменяющий создание PK (индекса).

(15) конфигурация дописана, добавлен робот и работа с ШК. Документы, справочники и регистры не тронуты
(16) спасибо, в копилку
(17) что такое ИР и где его взять?
(18) спасибо, буду пробовать
(19) Михаил, можно поподробнее про тригер Dbl.. в SQL новичок

(20) > про тригер Dbl.. в SQL

Подобные действия в SQL не решают проблему наличия ошибочных данных в регистре.
К тому же не совсем понятно как такие манипуляция с базой в скуле отразятся на корректности работы самой 1С в дальнейшем.

Это не для нубов в SQL.

(20) ИР: http://goo.gl/VihKW3

(20)
я написал пост основываясь на Вашем утверждении
"Думаю этот режим позволит мне загрузить базу в SQL и средствами SQL поправить найденные ошибки".

если Вы в sql новичок (при стаже на форуме 9 лет ) и не умеете пользоваться поисковыми сервисами.

то мой совет не для Вас