Ошибка при попытке вставки записи с неуникальным значением ссылки 1с

Обновлено: 07.07.2024

1С УТ 11.1 8.2.19.80 при попытке перепроведения отчета о розничных продажах за определенное число выдает ошибку: ошибка при попытке вставки записи с неуникальным значением ссылки таблица accumrg1. Подробнее>>

Сделайте копию базы и проведите тестирование и исправление

Сделайте копию базы и проведите тестирование и исправление

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

Еще из легких способов отменить проведения Отчетов о РП, сделать тестирование и провести эти документы. Если нет тогда нужно смотреть регистр накопления.

попробуйте в таком порядке
1. скопировать документ, но не проводить
2. старый пометить на удаление
3. удалить помеченные
4. сделать тестирование с галками - исправлять, удалять, очищать, реструктуризировать
5. провести новый

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

Вот так мне и сказали программисты из 1С .. надо ручками)))). Сама я так , как вы написали не смогу., это точно. путем проверки бэкапов выявленно , что 20.11.2015 все остатки в порядке, а 24,11,2015 уже плывут. Думаем мы как раз сделали тестирование и исправление. в этот промежуток времени. и после него все так произошло. что то оно не так поправило.

Елена если база файловая, то скопируйте ее в новое место. Сделайте оптимизацию и проверку жесткого диска. Потом вверните базу на место.
После этого сделайте реиндексацию базы и только потом попробуйте перепровести документ.
Судя по всему указанная таблица это регистр накопления. Поможет только полное перепроведение документов с 20 числа по последнее число.

Попробуйте обновить платформу и провести "тестирование и исправление"

Не поможет 100% полетела таблица остатков. Если база SQL то реиндексация средствами SQL, если файловая то реиндексация. Без удаления объектов из базы. Потом полное перепроведение документов.

Для участия в обсуждении Вам необходимо авторизоваться либо зарегистрироваться

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

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

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

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

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

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

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

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

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

Ошибка возникает, если в базе есть у каких-то объектов, реквизитов, субконто - значение NULL, а у них такого значения быть не может. И появляется такая ошибка только в SQL базах. Т.е. если такую базу выгрузить в файловую, то там уже этой ошибки не будет. Т.к. у файловой базы свои таблицы (всего 4 шт.), а у SQL свои. И SQL база критично реагирует на такие значения в своих таблицах.

Эта проблема не решается никакими тестированиями (ни внешним, ни внутренним) ни в каких вариантах баз (SQL или файловая) и даже Процедурой _1sp_DBReindex в менеджере SQL, которая вроде как должна проводить реструктуризацию таблиц в SQL.

.НО так заменить NULL в SQL базе не получится, во время выполнения обработки будет выдана та же самая ошибка. Поэтому необходимо сделать так:

1. Выгрузить уже рабочую, переведённую на КОРП версию, SQL базу в dt’шник (в конфигураторе Администрирование – Выгрузить базу – выберите куда выгрузить базу в виде файла *.dt)

2. Загрузить dt’шник в файловую базу (в ненужной или заранее подготовленной, чистой, файловой базе, в конфигураторе Администрирование – Загрузить базу – выбрать выгруженный ранее dt’шник)

3. Выполнить обработку в файловой базе (там ошибки не будет и все NULL’ы корректно заменяться) (как выполнить обработку описано ниже)

5. Теперь наоборот выгрузить dt’шник из файловой базы и загрузить его в SQL базу. Теперь при проведении обработанных документов ошибки выходить не будет.

В обработке необходимо указать период, за который необходимо обработать документы (можно за весь период в котором ведётся учёт в базе) и нажать «Заполнить табличную часть». После чего можно галками пометить какие документы обработать (можно выбрать все) и нажать кнопку «Выполнить обработку».

Соответственно если у кого-то такая же ошибка, но НЕ после перехода на КОРП, а на пример после обмена, загрузки каких-то данных, выполнения каких-то обработок и т.д. То необходимо выявить, где присвоилось значение NULL в конкретном документе/справочнике и подобным способом убрать этот NULL но уже своей обработкой, но в том порядке, как описано выше. Помните, что NULL может быть, как в проводках документа, в т.ч. не только бухгалтерских, так и где-нибудь на форме документа/справочника, в каком-нибудь реквизите, но в таком случае он наверно даже не откроется.

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

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

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

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

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

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

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

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

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

Читайте также: