Microsoft SQL Server Native Client 11.0: Не удается вставить повторяющуюся строку ключа в объект «dbo._AccRgAT118760» с уникальным индексом «_AccR118760_ByPeriod_TRRRRN». Повторяющееся значение ключа: (ноя 1 5999 12:00AM, 0xab52f3e52b35efa847b0cfef9c90ff9d, 0x95eb00112f2a1abf11dac09f12116a47, NULL, NULL, NULL, NULL, 0).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=E, native=2601, line=1
Техническая информация:
Ошибка при чтении изменений при обмене РИБ: {ОбщийМодуль.ПроцедурыОбменаДанными.Модуль(1559)}: Ошибка при вызове метода контекста (ПрочитатьИзменения): Попытка вставки неуникального значения в уникальный индекс:
Для ее решения делаем следующее:
1. Переходим на сервер SQL и запускаем SQL Server Management Studio
2. Находим сбойную базу в списке баз.
3. Нажимаем ПКМ и выбираем «Создать запрос»
4. В окне запроса пишем код для поиска данных в таблице:
SELECT * FROM [название_таблицы]
WHERE [название_столбца_1] = [что_ищем_1] and [название_столбца_2] = [что_ищем_2] and … [название_столбца_N] = [что_ищем_N]
Пример:
SELECT * FROM _AccRgAT118760
WHERE _AccountRRef = 0xab52f3e52b35efa847b0cfef9c90ff9d and _Fld18737RRef = 0x95eb00112f2a1abf11dac09f12116a47
- _AccRgAT118760 – название таблице в котором произошел сбой. Оно отображается в окне ошибки в 1С.
- _AccountRRef – название столбца_1 где будем искать.
- 0xab52f3e52b35efa847b0cfef9c90ff9d – значение_1 которое будем искать. Оно отображается в окне ошибки в 1С.
- _Fld18737RRef – название столбца_2 где будем искать.
- 0x95eb00112f2a1abf11dac09f12116a47 – значение_2 которое будем искать. Оно отображается в окне ошибки в 1С.
Название столбцов можно посмотреть следующем образом:
— Развернуть базу, нажав плюсик напротив базы
— Развернуть папку «Таблицы», нажав на плюсик напротив этой папки
— Найти в списке нашу таблицу
— Нажать ПКМ на таблицу и выбрать пункт «Выбрать первые 1000 строк»
— Появится окно с запросом и ниже окно с данными
Пример запроса:
/****** Скрипт для команды SelectTopNRows из среды SSMS ******/
SELECT TOP 1000 [_Period]
,[_AccountRRef]
,[_Fld18737RRef]
,[_Fld18738RRef]
,[_Value1_TYPE]
,[_Value1_RTRef]
,[_Value1_RRRef]
,[_Fld18739]
,[_TurnoverDt18751]
,[_TurnoverCt18752]
,[_Turnover18753]
,[_Fld18740]
,[_TurnoverDt18754]
,[_TurnoverCt18755]
,[_Turnover18756]
,[_Fld18741]
,[_TurnoverDt18757]
,[_TurnoverCt18758]
,[_Turnover18759]
,[_Splitter]
FROM [rzdp_cb].[dbo].[_AccRgAT118760]
— В запросе мы увидим название всех столбцов присутствующих в таблице. Эти названия мы можем скопировать для своего запроса.
- После того как мы написали код запроса, нажимаем кнопку «Выполнить» или F5 на клавиатуре.
- Наш код выполнится и выдаст в окне ниже значения таблицы.
- В это таблице мы ищем строку которая подходит по параметрам написанным в сообщении об ошибке (Пример: ноя 1 5999 12:00AM, 0xab52f3e52b35efa847b0cfef9c90ff9d, 0x95eb00112f2a1abf11dac09f12116a47, <NULL>, <NULL>, <NULL>, <NULL>, 0)
- Первое, на что надо обратить внимание, это на дату и искать с начало по ней. Найдя совпадения по дате, смотрим другие столбцы, они должны содержать значение NULL, а также, возможно, какую-нибудь сумму (в окне ошибки в 1С суммы не показываются)
- Нажимаем ПКМ на сбойную базу и выбираем «Создать запрос»
- В окне запроса пишем код удаления объекта:
USE [название_базы]
GO
DELETE FROM [название_таблицы]
WHERE [название_столбца_1] = [значение_поиска_1] and [название_столбца_2] = [значение_поиска_2] and [название_столбца_3] = [значение_поиска_3] and … [название_столбца_N] = [значение_поиска_N]
GO
Пример:
USE test_stand_2_cb
GO
DELETE FROM _AccRgAT118760
WHERE _AccountRRef = 0xab52f3e52b35efa847b0cfef9c90ff9d and _Fld18737RRef = 0x95eb00112f2a1abf11dac09f12116a47 and _Fld18739 = -1500.00
GO
test_stand_2_cb – название нашей сбойной базы
_AccRgAT118760 – таблица, в которой будем производить удаление объекта
_AccountRRef – столбец_1, в котором будем искать параметр для удаления
0xab52f3e52b35efa847b0cfef9c90ff9d – значение_1, которое должно стоять в столбце_1
_Fld18737RRef – столбец_2, в котором будем искать параметр для удаления
0x95eb00112f2a1abf11dac09f12116a47 – значение_2, которое должно стоять в столбце_2
_Fld18739 – столбец_3, в котором будем искать параметр для удаления
-1500.00 – сумма, которая должна стоять в столбце_3. Так как первое и второе значение будет содержаться во многих строках в таблице, нам нужно будет третье уникальное значение, по которому будет происходить поиск для удаления. Сумма нам может в этом помочь, т.к. значение суммы может совпадать с суммой сбойного документа.
- После написания запрос на удаления значения из таблицы нажимаем кнопку «Выполнить» или F5 на клавиатуре.
- После выполнения процедуры в SQL мы можем произвести нужные нами манипуляции со сбойным документом, которые ранее выдавали нам ошибку.
- Так же крайне желательно произвести пересчет итогов и проверить обороты.





Очень бы хотелось узнать, по какой причине возможно такое? Что такое смогли сделать пользователи, что 1С вываливается в такую ошибку.
А еще можно просто отключить использование итогов, выполнить обмен и включить использование итогов обратно… Индекс полностью пересоздастся (AccRg — это таблица регистра бухгалтерского, если ничего не путаю) и все будет хорошо.
(1)Обычно такого рода ошибка появляется (у нас) при изменении структуры счета: например признака «суммовой» по одному из субконто, или что-то подобное… Но не каждый раз. Предполагаю, что это как-то связанно с тем в каком порядке в фале обмена идет информация об изменении — видимо бывает так, что сначала пытаются загрузится движения, а потом — изменения плана счетов. Тогда пересчет существующих движений еще не произошел и вставка новых движений (и их индексация) конфликтует с ними… Ну сугубо мои домыслы — глубокий анализ не проводил…
В нашем случае произошел сбой в SQL, повредился один из авансовых отчетов. Что ты с ним не делай, появлялась такая ошибка. В пример я скопировал ошибку из обмена, в котором были изменения для этого документа. По факту получилось что вовремя сбоя происходили манипуляции с документом и проводки по нему записались частично. Повторно записать или удалить проводки при помощи 1С не получалось, всегда появлялась ошибка «Не удается вставить повторяющуюся строку ключа в объект». Перепробовав все что можно помог только этот способ с нахождением битых данных и удаление их через SQL.
(4)Т.е. вы хотите сказать, что пробовали отключить итоги и провести какие-либо из указанных действий и получали то-же сообщение? Простите, но не верю! Сообщение касается вставки неуникального индекса таблицы AccRgAT, которая является таблицей итогов (, при отключенных итогах этого никак не может происходить. То же и при перепроведении — эта таблица при отключенных итогах не работает. А при последующем включении итогов они полностью пересчитываются и индекс пересоздается… Я бы не стал настаивать, но операция включения/выключения итогов в моем понимании на порядок проще и, главное, безопаснее, чем прямое вмешательство в SQL… Даже при хорошем знании структуры таблиц это рискованно, а вы, как мне кажется, действовали что называется «по наитию»… ) Проблема решена и это хорошо, но я бы не рекомендовал этот метод, как «best practices».
Я не утверждаю что это золотой грааль решения данной проблемы, но данный способ нам помог и я решил им поделиться. SQL-я боятся не надо и если все делать грамотно и аккуратно, то ни чего не сломаешь.
(6) Как говорил один знакомый электрик, люди боятся электричества в двух случаях: когда не знают, как это работает и когда ТОЧНО знают, как это работает. А не боятся — когда ДУМАЮТ, что знают… С SQL — тоже самое. И ваш случай, к сожалению, последний.
Поясню.
AccRgAT — таблица ИТОГОВ по счету.
_AccountRRef — Ссылка на счет.
_Fld18737RRef — согласно документации — измерение или ресурс… Предположу ,что в вашем случае — измерение, и думаю, что это — Организация.
-1500 — Собственно итог.
Что выделаете? Вы удаляете запись из таблицы итогов. Напрямую из таблицы. По какому-то счету. После чего у вас все проводится и вы думаете, что исправили ошибку.
После этого вы итоге не пересчитываете, а счастливо продолжаете жить дальше…
Хотите совет? 😉 Пересчитайте итоги. Бухгалтерские. Полностью. Можно еще построить оборотку по предположительно проблемным счетам — до и после этой операции. И сравнить. Возможно удивитесь.
Итоги после этого пересчитали и оборотку формировали, все норм.
Могу да же больше сказать, эта проблема возникла в последний день сдачи отчетности и проблему надо было решать оперативно. Отчетность сдана успешна.
(8) Хорошо! Если пересчитали итоги — то в принципе ничего страшного не произошло… Неплохо бы написать об этом в статью 13 пунктом…. 😉
Добавил)))
можно проблему решить куда проще, просто создаем запись с такой ссылкой в 1с, у меня была проблема:
была вскуле запись о строке табличной части документа, но небыло самого документа, я просто создал пустой документ с этой ссылкой, а потом он просто обменом перезаписался
пример
СсылкаНаЧек = xmlЗначение(Тип(«ДокументСсылка.ЧекККМ»), «87cc624b-6f51-11e9-961e-002511799f8a»);
Об = Документы.ЧекККМ.СоздатьДокумент();
Об.УстановитьСсылкуНового(СсылкаНаЧек);
Об.Дата = Дата(2000,1,1);
Об.ОбменДанными.Загрузка = Истина;
Об.ПометкаУдаления = Истина;
Об.Записать();
в случае с регистром накопления, создаем пустой документ и проводим его, он сам очистит все записи лишние из регистра накопления или перезапишет их и будет все ок
Более простое решение:
1. Копию базу сделали.
2. По стандарту: Кеш почистили, Тестирование и исправление данных 2 раза запустили крыжики все, первый раз очистить, второй раз создать.
3. Расшифровываем косячный объект согласно инструкции
в Вашем и моем случае это бухгалтерские итоги.
У меня на 01.12.4018г, у Вас «ноя 1 5999 12:00AM» — 1.11.5999г
3. Заходим в Все функции / Стандартные / Управление итогами
Внизу справа гиперссылка Полные возможности
Находим регистр бухгалтерии
Журнал проводок (бухгалтерский и налоговый учет) (регистр бухгалтерии)
Спозиционировались на нем, нажали в командной панели Пересчет, Пересчитать Итоги,
Затем там же жмем кнопку Установить период итогов и меняем максимальный или минимальный (у кого какой глюканул) период Ок, и возвращаем период назад и опять Ок.
4. Выгрузили базу в файл и загрузили на место.
У меня все работает.