Добрый день!
Занимаюсь разработкой конфигураций на основе платформы 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С, выполнилось тестирование базы с режимом «Реструктуризация таблиц информационной базы», данная процедура пересоздала индексы в таблице, и дальнейшие манипуляции, при работе с метаданными конфигурации, стали происходить без каких либо ошибок.
Ошибка загрузки информационной базы. |
Я |
09.09.14 — 09:08
Всем привет! Появляется вот такая ошибка если загружать базу в Sql вариант, в файловой все нормально, как ее можно исправить?
Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 11.0: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем «dbo._ChrcChngR14332» и индекса с именем «_ChrcC14332_ByNodeMsg_RNR». Повторяющееся значение ключа: (0x00000014, 0x941c0015f2efde5411e3bbbbb6d19ef7, <NULL>, 0x8642f7481ff1ee7b48906540f37d661e).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1
1 — 09.09.14 — 09:11
ТИИС для файловой…
2 — 09.09.14 — 09:12
Уже делал несколько раз, не помогло (
3 — 09.09.14 — 09:12
Планы видов характеристик
4 — 09.09.14 — 09:12
Не спасет..
5 — 09.09.14 — 09:13
Платформа какая?
6 — 09.09.14 — 09:13
Платформа 1С 8.3.5.1119
7 — 09.09.14 — 09:14
Экстремал.. Попробуй поднять под 4.465 хотя бы
8 — 09.09.14 — 09:15
«Загружать базу в SQL» — выгружал как, чем, на какой платформе крутилась?
9 — 09.09.14 — 09:15
+ все динамические обновления были завершены перед выгрузкой?
10 — 09.09.14 — 09:16
У меня сейчас стоит УТ 11.1.4.13, не типовая, я хочу загрузить не типовую конфигурацию 11.1.7.56 и выскакивает такая ошибка, пробовал загрузить типовую 11.1.7.56, то же самое, обновлял в файлов варианте, потом пробовал подгрузить базу в Sql и опять то же самое
11 — 09.09.14 — 09:17
(10) поставь на сиквел пустую 11.1.7.56 и сделай выгрузку/загрузку в идентичную конфигурацию из файловой
12 — 09.09.14 — 09:18
(8) Выгрузку и загрузку делаю через конфигуратор 1С, ну когда начинали работать все крутилось на 8.3.4.482
13 — 09.09.14 — 09:18
нихрена не понял.. ты конфигурацию чтоли загружаешь?
14 — 09.09.14 — 09:19
(13) я пытался грузить конфу или базу
15 — 09.09.14 — 09:21
(13) мне надо загрузить или уже обновленную базу или конфигурацию для обновления базы
16 — 09.09.14 — 09:22
Почему именно загрузить? Сравнить и объединить не хочешь?
17 — 09.09.14 — 09:22
(11) я Вас не совсем понял, еще не полностью проснулся, можно подробнее )
18 — 09.09.14 — 09:22
(16) и это пробовал, результат тот же
19 — 09.09.14 — 09:22
Загрузка может порушить как раз индексы и структуру
20 — 09.09.14 — 09:23
Короче, пробуй под 4.465.
5ка еще сырая
21 — 09.09.14 — 09:24
(17) берешь cf от файловой, создаешь пустую базу на стквеле, загрушаешь cf, берешь обработку выгрузказагрузкавидентичнуюконифграцию выгружаешь в xml из файловой, загружаешь в сиквельную
22 — 09.09.14 — 09:24
Так пишут что для этой конфигурации 11.1.7.56,Внимание! Текущая версия конфигурации «Управление торговлей», редакция 11.1 предназначена для использования с версией системы 1С:Предприятие 8 не ниже 8.3.5.1119.
23 — 09.09.14 — 09:25
(0)>Появляется вот такая ошибка если загружать базу в Sql вариант, в файловой все нормально
— потому и нормально, что 1С — это не СУБД.
Она не отслеживает уникальность. А SQL — отслеживает.
(19)>Загрузка может порушить как раз индексы и структуру
— хватит ерунду говорить
24 — 09.09.14 — 09:25
(21)>берешь cf от файловой, создаешь пустую базу на стквеле
— бессмысленно
25 — 09.09.14 — 09:25
(23) Ну-ну..
26 — 09.09.14 — 09:26
Здесь однозначно — надо выявлять (Tool1CD), какие записи-ключи задвоились, и их править каким-либо образом — в хексе, или еще как сможешь (например, удалить объекты из базы)
27 — 09.09.14 — 09:26
(24) Ты решение предложи. А то флудить тут все умеют
28 — 09.09.14 — 09:27
(25) гну-гну
что-что, а загрузка-выгрузка ПРАВИТ структуру 1С, а не ломает. Это используется везде и всюду, за неименеием лучшего.
29 — 09.09.14 — 09:27
(27) вот и не флуди больше.
А думай.
30 — 09.09.14 — 09:28
(27) а индексы, молодой человек, каждый раз можно создать заново. На то они и индексы.
31 — 09.09.14 — 09:29
(0)вот эти два ключа и ищи:
— 941c0015f2efde5411e3bbbbb6d19ef7
— 8642f7481ff1ee7b48906540f37d661e
32 — 09.09.14 — 09:31
(21) у него ДАННЫЕ битые (ключи задвоены, что не редкость в файловой 1С, когда она постоянно завершается некорректно/электричество отключается/много пользователей-зависает).
MS SQL (он — ТОЧНО), исключает саму возможность задвоения ключей на уровне структуры (уникальность записи).
33 — 09.09.14 — 09:34
(21)>берешь обработку выгрузказагрузкавидентичнуюконифграцию выгружаешь в xml из файловой, загружаешь в сиквельную
— можно и в выгрузке XML поправить ключи, но лучше это сделать в среде, где можно корректировать записи на уровне таблиц данных. Иначе может структура побиться из-за несоблюдения формата, и вообще ничего не загрузится обратно.
34 — 09.09.14 — 09:36
(0)>ChrcChng
— это что вообще за объект — СвойстваИКатегории, что ли? Всякие подобные метаданные частенько так бьются.
35 — 09.09.14 — 09:55
(32) пару раз такие завершения были, а кстета, забыл еще вот что написать. Если выгрузить сейчас базу с конфой 11.1.4.13 и загрузить ее в Sql то будет все нормально, а вот обновить конфу уже не получается
36 — 09.09.14 — 09:58
(31) а где эти ключи искать надо? я загружал свою базу с конфой 11.1.4.13 на Sql (мы так изначально и работаем) и находил там в таблице dbo.ChrcChngR14332, только что с ним делать дальше
37 — 09.09.14 — 10:08
Просто настал уже такой момент что надо обновить конфу УТ (11.1.4.13), только пробовал обновлять сразу на 11.1.7.56 и с ней возникает такая ошибка, может это проблема конфигурации?
38 — 09.09.14 — 10:20
(36)> я загружал свою базу с конфой 11.1.4.13 на Sql (
— если УЖЕ загрузил в SQL, этой ошибки не будет никогда.
Ошибка именно в том наборе данных, который не загружается.
39 — 09.09.14 — 10:22
(37)>и с ней возникает такая ошибка, может это проблема конфигурации?
— Ошибка в задвоении. Все.
Если уберешь каким-либо способом задвоение (может, тут и обновление поможет — вправит на место типовые ключи), то и ок.
Ты даже не посомтрел, что за данные за этими ключами.
40 — 09.09.14 — 10:24
(35)>а вот обновить конфу уже не получается
— сделай все в файловой (обновление и все такое), и попробуй удалить «лишние» объекты после обновления. Вместе с объектами удалятся и ключи, и SQL уже не будет ругаться.
Но для этого тебе нужно выяснить, что за объекты с задвоенными ключами.
41 — 09.09.14 — 10:26
(40) «Но для этого тебе нужно выяснить, что за объекты с задвоенными ключами.»- а как это можно сделать?
42 — 09.09.14 — 10:27
(36)>я загружал свою базу с конфой 11.1.4.13 на Sql (мы так изначально и работаем) и находил там в таблице dbo.ChrcChngR14332
— тут и не будет никаких задвоений, задвоенность «появляется» после обновления.
Точнее, страые объекты либо не удаляются, как надо, либо не надписываются. А может, и еще как-то остаются, но итог — «их» ключи мешают «новым» данным с теми же ключами.
43 — 09.09.14 — 10:28
(41)Tool1Cd на файловой «битой» базе. И Вперед, смотреть и разбираться.
44 — 09.09.14 — 10:30
(43) я так понимаю на файловой, но уже с обновленной конфой 11.1.7.56?
45 — 09.09.14 — 10:30
(42)>»их» ключи мешают «новым» данным с теми же ключами.
— типовой пример — в ПланеВидовРасчета оказывается два предопределенных вида начисления.
Соответсвенно, один надо каким-то образом удалить, и так, чтобы ссылочность не пострадала (т.е. сначала все ссылке «перевести» на новый, оставляемый объект).
46 — 09.09.14 — 10:31
(44) да
В любом другом случае все ключи у тебя будут уникальными.
47 — 09.09.14 — 10:47
А эта прога Tool1Cd поддерживает версию 8.3.5.1119? Если можно дай пожалуйста ссылку на скачивание, а то я в гугле нашел или с вирусами или платную (
48 — 09.09.14 — 15:23
МихаилМ
49 — 09.09.14 — 15:33
+(48)
либо отмените создание индекса (PK)
по аналогии с
v8: Ошибка в базе. Ошибка в таблице Config.
после загрузки исправьте неуникальность
и создайте индекс
Ко мне обратился системный администратор одного из клиентов с проблемой, представленной на картинке:
Я сразу понял, что он пытается загрузить данные в базу из DT, подумал, что он пытается восстановить базу из архива и сказал всё что я думаю об архивации баз 1С в DT: «DT — ненадежный формат, 1С его не рекомендует использовать для бэкапов«.
Но, к счастью, оказалось, что админ просто пытается перенести базу из файловой в SQL. Полный текст ошибки оказался такой:
Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Нарушено условие уникальности данных.
Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 10.0: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем "dbo._InfoRg29405" и индекса с именем "_InfoRg29405_1". Повторяющееся значение ключа: (0x20002000200020002000200020002000, 20002000200, 200020002000, 2001-01-01 20:00:20).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1Я попытался найти обработку, которая позволит по идентификатору регистра определить, что это за регистр. Но увы, у меня была версия только для обычных форм «Список метаданных«.
Тогда я нашел другой способ определения идентификатора, через выгрузку файлов базы данных.
Но администратор оказался шустрее, он запустил ТИИ с удалением битых ссылок, в итоге чего была определена проблема:
Проверка логической целостности. РегистрСведений.ЗамерыВремени.Измерение.КлючеваяОперация <Объект не найден> (77:20002000200020002000200020002000):20 002 000 200:200 020 002 000:01.01.0001 20:00:20
Неверная ссылка. Запись удалена.В итоге стало ясно, что битая запись была в регистре «Замеры времени», в общем то бесполезном.
Так удалось перенести базу в SQL-формат. Иногда пользователи находят более простые решения, чем программисты.
Объем: 0.2 час.
See below timeline:
1 — 04:58 (Server A) — REORG of PK index on Table1 in DB_XXX started.
2 — 05:00 (Server A) — Create SNAPManager copy of DB_XXX
3 — 05:01 (Server B) — SNAPManager restore of DB_XXX_Copy.
4 — 05:11 (Server A) — REORG of PK index on Table1 in DB_XXX Complete.
Note: SNAP copy taken mid REORG.
5 — 05:25 (Server B) — CREATE NONCLUSTERED INDEX on Table1 failed with the following error: «CREATE UNIQUE INDEX statement terminated because a duplicate key was found for the object name ‘dbo.Table1’ and the index name ‘NonClusteredIndex’. The duplicate key value is (111, 222).»
- Firstly, The error suggests the index being created is a UNIQUE INDEX, however the error is generated when running a CREATE NONCLUSTERED statement.
- Secondly, The Duplicate Key error references 2 values (111,222), but the PK is on one column and the NON CLUSTERED INDEX is on one column.
The only thing I can think of is that because the SNAP copy was taken in the middle of a REORG, the PK on this table was in an inconsistent state on the copy? Here is a link to a similar issue: https://stackoverflow.com/questions/3398348/unique-index-error-when-creating-non-unique-index-sql-server.
Is anyone able to explain or verify this behaviour?
Thanks
Вам встретилось сообщение, содержащее строки:
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