Выполнение инструкции create unique index прервано

Добрый день!

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

В процессе обновления информационной базы произошла критическая ошибка
по причине:
Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 11.0: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем «dbo._AccRg2024NG» и индекса с именем «_AccRg2024_ByPeriod_TRNNG». Повторяющееся значение ключа: (сен 30 4013 12:00AM, 0x0000001c, 0x83fd001b78e2ed3011e342e2cb8d7e1c, 1).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1

Так как копии разворачивались только в целях внесения изменений в конфигурацию и тестирования, этой ошибке не предавали особого значения, пока не понадобилось добавить предопределенный счет. При обновлении конфигурации происходила реструктуризация регистра бухгалтерии и вываливалась данная не приглядная ошибка. Дальнейшее обновление прекращалось. Гугление данного вопроса результатов не дало. пришлось разбираться самим.

Выяснение имени таблицы 1С связанной с объектом определяется функцией ПолучитьСтруктуруХраненияБазыДанных, там же можно поглядеть и состав индексов.

Как оказалось данные индексы в таблице SQL «_AccRg2024» отсутствовали физически. При дальнейшем анализе данных уже средствами SQL выяснилось, что не уникальными были номера записей в разрезе Периода — [_Period], регистратора — [_RecorderRRef] и номер записи [_LineNo], из за чего и не происходила реструктуризация таблицы. Кто и как умудрился удалить эти индексы история умалчивает, данный факт восстановлению не подлежит.

Вылечилась данная ситуация следующим запросом:

USE [DB]
GO

CREATE TABLE #TempRecorder (_RecorderRRef BINARY(16))
GO

INSERT INTO #TempRecorder 
	SELECT T.[_RecorderRRef]
	FROM (SELECT COUNT(*) as _count , T1.[_Period]  ,T1.[_RecorderRRef] ,T1.[_LineNo]      
			FROM [dbo].[_AccRg2024] AS T1	 
			GROUP BY T1.[_Period] ,T1.[_RecorderRRef]  ,T1.[_LineNo]
			HAVING count(*) > 1 ) AS T
	
	--WHERE T.[_RecorderRRef] = 0xBA80000C29053BCD11E2FF4303EA5AA7

	GROUP BY T.[_RecorderRRef]

DECLARE @_Count numeric(10), @_Period datetime, @_RecorderRRef binary(16), @_LineNo numeric(9,0);

DECLARE @i int;
SET @i = 0;

DECLARE _Recorder_Cursor CURSOR FOR
SELECT * FROM #TempRecorder;

OPEN _Recorder_Cursor
FETCH NEXT FROM _Recorder_Cursor INTO @_RecorderRRef;

WHILE @@FETCH_STATUS = 0
   
	BEGIN
		DECLARE _Cursor CURSOR FOR
		SELECT [_Period], [_LineNo] FROM [dbo].[_AccRg2024]
		WHERE [_RecorderRRef] = @_RecorderRRef

		OPEN _Cursor

		SET @i=0;

		FETCH NEXT FROM _Cursor INTO @_Period, @_LineNo

		WHILE @@FETCH_STATUS = 0

			BEGIN
				SET @i = @i + 1 

				UPDATE [dbo].[_AccRg2024] SET [_LineNo] = @i
				WHERE CURRENT OF _Cursor

				FETCH NEXT FROM _Cursor INTO @_Period, @_LineNo

			END;

		CLOSE _Cursor;
		DEALLOCATE _Cursor;

	FETCH NEXT FROM _Recorder_Cursor INTO @_RecorderRRef;
	
	END

CLOSE _Recorder_Cursor;
DEALLOCATE _Recorder_Cursor;

GO

DROP TABLE #TempRecorder
GO

Изначально определяются неуникальные записи, выбираются регистраторы и в цикле происходит пере нумерация строк.

После этого, уже средствами 1С, выполнилось тестирование базы с режимом «Реструктуризация таблиц информационной базы», данная процедура пересоздала индексы в таблице, и дальнейшие манипуляции, при работе с метаданными конфигурации, стали происходить без каких либо ошибок.

Ошибка обновления — повтояющийся индекс

Автор kmvtut, 10 янв 2018, 13:11

0 Пользователей и 1 гость просматривают эту тему.

1

CONVERT(char(36),CAST(_Fld20860_RTRef as uniqueidentifier))

Наверх

Вам встретилось сообщение, содержащее строки:
Microsoft OLE DB Provider for SQL Server: CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID
или
Cannot I_nsert duplicate key row in object
или
Попытка вставки неуникального значения в уникальный индекс.

Варианты решения:

1. В SQL Server managment studio физически уничтожаем сбойный индекс (в моем случае это был индекс по таблице итогов регистра бухгалтерии). В 1С распроводим сбойные документы. В режиме тестирования и исправления ставим галки реиндексация таблиц + пересчет итогов. 1С воссоздает индекс уже без ошибки. Проводим ранее сбоившие документы.

2. 1) С помощью Management Studio 2005 сгенерировала create-скрипт на создание индекса, который глючил, и сохранила в файлик.
2) Вручную убила косячный индекс из таблицы _AccumRgTn19455
3) Запустила запрос вида

Код SQL

 S_elect count(*), поля_индекса

FROM AccumRgTn19455

GROUP BY поля_индекса

HAVING count(*)>1   

После того, как индекс был убит, у меня отобразилось 15 дублирующихся записей, хотя до выполнения п.2 запрос ничего не возвращал.
4) Просмотрела все записи и вручную почистила дубликаты. На самом деле, я ещё пользовалась обработкой «Структура отчёта», чтобы понять, с чем вообще имею дело. Оказалось, что в таблице _AccumRgTn19455 хранится регистр накопления «Выпуск продукции (налоговый учёт)». Я ещё поковырялась sql-запросами, выявила 15 неуникальных документов и после окончания всех действ проверила в 1С, что эти документы проводятся нормально, без ошибок. Просто так чистить таблицы наобум, конечно, не стоит: важно понимать, что чистится и чем это может обернуться.
5) Запустила запрос на создание индекса, который был сохранён в файле.
6) Перевела базу в однопользовательский режим и запустила dbcc checkdb — на этот раз ни одной ошибки не выдалось.
7) Перевела базу обратно в однопользовательский режим.
Всё… проблема побеждена. Ну ещё в 1С запустила «Тестирование и исправление», там тоже всё прошло нормально, перестало ругаться на неуникальный индекс.

3. Если неуникальность заключается в датах с нулевыми значениями, то проблема решается созданием базы с параметром смещения равным 2000.

1. Если проблема загрузкой базы данных, то:
1.1. Если Вы делаете загрузку (используйете dt-файл) в базу MS SQL Server, то при создании базы перед загрузкой укажите смещение дат — 2000.
Если уже база создана со смещением 0, то создайте новую с 2000.

1.2. Если есть возможность в файловом варианте работать с базой, то выполните Тестирование и Исправление, а также Конфигурация — Проверка конфигурации — Проверка логической целостности конфигурации + Поиск некорректных ссылок.

1.3. Если нет файлового варианта, попробуйте загрузить из DT в клиент-серверный вариант с DB2 (который менее требователен к уникальности), и затем выполнить Тестирование и Исправление, а также Конфигурация — Проверка конфигурации — Проверка логической целостности конфигурации + Поиск некорректных ссылок.

1.4. Для локализации проблемы можно определить данные объекта, загрузка которого не удалась. Для этого надо включить во время загрузки трассировку в утилите Profiler или включите запись в технологический журнал событий DBMSSQL и EXCP.

2. Если проблема неуникальности проявляется во время работы пользователей:

2.1. Найти с помощью метода пункта 1.4 проблемный запрос.

2.1.2. Иногда ошибка возникает во время исполнения запросов, например:

Данная ошибка возникает из-за того что в модуле регистра накопления «Рабочее время работников организаций» в процедуре «ЗарегистрироватьПерерасчеты» в запросе не стоит служебное слово «РАЗЛИЧНЫЕ».

Код 1C v 8.х

 Т.е. должно быть:

Запрос = Новый Запрос(

"ВЫБРАТЬ РАЗЛИЧНЫЕ

| Основные.ФизЛицо,

. . . . .   

В последних выпущенных релизах ЗУП и УПП ошибка не возникает, т.к. там стоит «РАЗЛИЧНЫЕ».

2.2. После нахождения проблемного индекса из предыдущего пункта, необходимо найти неуникальную запись.
2.2.1. «Рыба» скрипта для определения неуникальных записей с помощью SQL:

Код SQL

 S_elect COUNT(*) Counter, <перечисление всех полей соответствующего индекса> from <имя таблицы>

GROUP BY <перечисление всех полей соответствующего индекса>

HAVING Counter > 1   

2.2.2 Пример. Индекс в ошибке называется «_Document140_VT1385_IntKeyIndNG».
Перечень полей таблицы:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394,_Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Перед выполнением приведенной ниже процедуры сделайте резервную копию базы данных.
Выполните в MS SQL Server Query Analizer:

Код SQL

 S_elect count(*), _Document140_IDRRef, _KeyField

from _Document140_VT1385

group by _Document140_IDRRef, _KeyField

having count(*) > 1   

С его помощью узнайте значения колонок _Document140_IDRRef, _KeyField, дублирующихся записей (id, key).

При помощи запроса:

Код SQL

 S_elect *

from _Document140_VT1385

where _Document140_IDRRef = id1 and _KeyField = key1 or _Document140_IDRRef = id2 and _KeyField = key2 or ...   

посмотрите на значения других колонок дублирующихся записей.
Если обе записи имеют осмысленные значения и эти значения разные, то исправьте значение _KeyField на уникальное. Для этого определите максимальное занятое значение _KeyField (keymax):

Код SQL

 S_elect max(_KeyField)

from _Document140_VT1385

where _Document140_IDRRef = id1   

Замените значение _KeyField в одной из повторяющихся записей на правильное:

Код SQL

 update _Document140_VT1385

set _KeyField = keymax + 1

where _Document140_IDRRef = id1 and _LineNo1386 = lineno1   

Здесь _LineNo1386 = — дополнительное условие, которое позволяет выбрать одну из двух повторяющихся записей.

Если одна (или обе) из повторяющихся записей имеет очевидно неправильное значение, то ее нужно удалить:

Код SQL

 delete from _Document140_VT1385

where _Document140_IDRRef = id1 and _LineNo1386 = lineno1   

Если повторяющиеся записи имеют одинаковые значения во всех колонках, то из них нужно оставить одну:

Код SQL

 S_elect distinct *

into #tmp1

from _Document140_VT1385

where _Document140_IDRRef = id1 and _KeyField = key1


delete from _Document140_VT1385

where _Document140_IDRRef = id1 and _KeyField = key1


I_nsert into _Document140_VT1385

S_elect #tmp1


D_rop table #tmp1   

Описанную процедуру необходимо выполнить для каждой пары повторяющихся записей.

2.2.3. Второй пример:

Код SQL

 S_elect COUNT(*) AS Expr2, _IDRRef AS Expr1, _Description

FROM _Reference8_

GROUP BY _IDRRef, _Description

HAVING (COUNT(*) > 1)   

2.3.4 Пример определения неуникальных записей с помощью запроса 1С:Предприятие:

Код 1C v 8.х

 ВЫБРАТЬ Справочник.Ссылка

ИЗ Справочник.Справочник КАК Справочник

СГРУППИРОВАТЬ ПО Справочник.Ссылка

ИМЕЮЩИЕ КОЛИЧЕСТВО(*) > 1