Ошибка "В процессе обновления информационной базы произошла критическая ошибка"

При обновлении конфигурации может возникнуть очень неприятная вещь!
В процессе обновления информационной базы произошла критическая ошибка по причине:
Попытка вставки неуникального значения в уникальный индекс: Далее текст самой ошибки.
Эту ошибку устранить довольно легко! А как, читайте дальше…

Предыстория

Нужно нам было создать новый регистр сведений «ЖурналОтслеживанияСообщений». Добавили в конфигурацию, загрузили данные. Затем пошла работа по оптимизации. Пришлось менять структуру регистра. Но не тут-то было!

Реорганизация

Тут все ясно. Записи стали неуникальными, нужно их удалить!

Самой простой способ это:

НоваяЗапись = РегистрыСведений.ЖурналОтслеживанияСообщений.СоздатьНаборЗаписей();
НоваяЗапись.Записать();

Таким методом мы очистим регистр в 1С очень быстро (но это будет и нашей ошибкой). 

Ошибка

Казалось бы, в регистре пусто, и можно обновлять 1С. Не хочу вас удивить, но будет снова ошибка:

Ошибка 1С

Что же представляет ошибка:

В процессе обновления информационной базы произошла критическая ошибка
по причине:
Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 11.0: The CREATE UNIQUE INDEX statement terminated because a duplicate key was found for the object name ‘dbo._InfoRgChngR34546NG’ and the index name ‘_InfoR34546_ByNodeMsg_RNTSRRRRRRNG’. The duplicate key value is (0x00000011, 0x80ca00155d03c00d11e54af2ae5400d7, <NULL>, Sep 27 4015 10:22PM, 768404, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1

Пояснение

Давайте разберемся со структурой SQL. У нас есть регистр «ЖурналОтслеживанияСообщений», он в SQL находится в таблице «_InfoR34546″. Проверить это вы можете специальными обработками или методом «тыка» (нам это не придется делать т.к. в тексте ошибки уже указано название таблицы). 

А теперь поясню, что же произошло. Когда мы загрузили данные в регистр, то в SQL они попали в таблицу «_InfoR34546″. Когда мы кодом в 1С очистили таблицу, то эти данные удалились из таблицы «_InfoR34546″, но они скопировались в таблицу «_InfoRgChngR34546″. Это и стало проблемой.

Решение

Для решения возникшей проблемы нам понадобится очистить SQL таблицу «_InfoRgChngR34546″.

Расскажу на примере «Microsoft SQL Server Management Studio». Заходим в «Management Studio». Находим нашу базу, открываем вкладку таблиц, кликаем на любую и жмем кнопку «Новый запрос»:Новый запрос. Теперь набираем запрос 

truncate table "_InfoRgChngR34546"

У вас может быть и другая таблица! Не забывайте!

И жмем выполнить или клавишу «F5». Вот такой должен быть результат:

Успех

Все, теперь можно спокойно обновлять 1С, и ошибки не будет!

6 Comments

  1. Danil.Potapov

    злодей. а что мешало при очистке не регистрировать на обмен или очистить штатными средствами.

    Reply
  2. Xershi

    (1) Dpotapov, купился на слова: //Способ 1 — быстрый и легкий. http://1cprofi.com/content/view/15/15

    Reply
  3. Danil.Potapov

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

    Reply
  4. Xershi

    (3) Dpotapov, да вы правы. Добавил на автомате регистр в тестовую базу, а он автоматом прописался в план-обмена удаленной копии. Т.к. я об этом не подозревал на этот момент, поэтому полез в SQL и там очистил таблицу.

    Теперь конечно понятно, что таблица «_InfoRgChngR34546» ничто иное как регистрация регистра для обмена и почистить эту таблицу можно через обработку «Регистрация изменений для обмена».

    Но повторюсь на тот момент это последнее, что пришло бы в голову!

    Reply
  5. IgorS

    По рукам бить программиста, который после каждой ошибки лезет «что-нибудь подправить» в СУБД.

    Reply
  6. Xershi

    (5) IgorS, ну не скажи. Вот если бы у тебя не было под рукой обработки «Регистрация изменений для обмена». То это решение как раз, то что нужно!

    Тем более, если мы понимаем, что делаем!

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *