Обнаружены дублирующиеся ключи в уникальных индексах таблицы 1с как исправить
Повторяющиеся ключи это значения из набора столбцов некоторой таблицы, которые встречаются в данной таблице более одного раза.
Потерянные проводки это строки таблицы _1SENTRY или _1SOPER.
Вы спросите – «Почему данные термины используются в заголовке темы вместе?». Потому, что часто (хотя и не всегда) потерянные проводки проявляются как строки с повторяющимися ключами.
Native errorКод ошибки SQL | SeverityУровень «серьезности» ошибки | Текст ошибки |
1505 | 14 | CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID %d. Most significant primary key is '%S_KEY'. |
Невозможно создать уникальный индекс так как в талибце найдены повторяющиеся ключи | ||
1508 | 14 | CREATE INDEX terminated because a duplicate row was found. Primary key is '%S_KEY'. |
Невозможно создать кластерный индекс так как в таблице найдены повторяющиеся ключи | ||
2601 | 14 | Cannot insert duplicate key row in object '%.*ls' with unique index '%.*ls'. |
Невозможно вставить строки (обновить строки) в таблице, так как для нее создан уникальный индекс и строка с таким ключом уже есть в таблице |
Первые две ошибки случаются когда предпринимается попытка создания индекса (уникального или кластерного). Третья ошибка происходит при попытке вставки записи (либо изменении поля существующей записи) и при этом нарушается уникальность уже существующего индекса.
В том же BOL в качестве способа нахождения повторяющихся ключей указан такой оператор:
Select field,…, fieldN form table group by field,…, fieldN,
здесь field,…, fieldN – набор полей таблицы, по которому создан индекс, уникальный которого нарушается. Это конечно неудобно, так как приходится пролистывать весь запрос для нахождения повторяющихся ключей. Удобнее будет использовать следующий запрос:
select field,…, fieldN, "Count"=count(*) from Table Group by field,…, fieldN having count(*)>1
После получения списка повторяющихся ключей, остается решить какие из них нужно оставить, а какие удалить.
- Поставить признак для документа, создающего бухгалтерские проводки, «Всегда создавать операцию». Данный способ лучше всего применять для конфигураций, которые еще не «в бою», то есть только на этапе создания. При разработке конфигурации для SQL платформы всегда ставьте признак «Всегда» ;) для уменьшения вероятности возникновения потерянных проводок.
- Отмена проведения + проведение документа (ов). Обычно не помогает документам, у которых не стоит признак создавать операцию всегда. И именно при проведении документа возникает данная ошибка.
- Выгрузка – загрузка данных. Очень действенный метод, но очень долгий.
- Тестирование + исправление конфигурации. Иногда помогает.
Что рекомендую. Сначала пробуйте отменить проведение документа и провести его заново. Иногда бывает трудно определить у какого документа потерялись проводки. В этом случае данная операция может занять столько же (если не больше) времени сколько загрузка и выгрузка. Если не поможет – тестирование + исправление конфигурации. Если не поможет – почистить проводки с помощью метода борьбы с повторяющимися ключами, провести документ(ы). Крайняя мера – загрузка – выгрузка. Изменение признака операции на «создавать всегда» приведет к пересчету бухгалтерских итогов, поэтому данная операция сравнима по времени с выгрузкой – загрузкой и тестированием с пересчетом итогов. Данную операцию я не применял, но думаю, что ее можно использовть вместо тестирования – исправления конфигурации. В любом случае если вы исправили положение, то для всех бухгалтерских документов лучше поставить признак создавать операцию всегда.
Еще в данной статье хотелось бы обратится к другой моей статье , в которой подробно был изложен способ нахождения потерянных проводок. Этот способ основывается на другом предположении, а именно на том, что потерянные проводки (операции) не принадлежат ни одному из документов. В статье был приведен скрипт, с помощью которого можно получить список потерянных проводок. На его основе легко получить другой скрипт, который сможет удалить такие проводки:
-- есть проводки по непроведенным документам
-- такое безобразие нужно "покоцать"
delete from _1sentry (nolock)
where docid in (select iddoc from _1sjourn (nolock)
where closed=0)
-- есть проводки, но нет соответствующих документов
-- такое безобразие нужно "покоцать"
delete from _1sentry (nolock)
where docid not in (select iddoc from _1sjourn (nolock))
-- есть проводки, но нет соответствующих операций
-- такое безобразие нужно "покоцать"
delete from _1sentry (nolock)
where docid not in (select docid from _1soper (nolock))
-- есть операции, но нет соответствующих документов
-- такое безобразие нужно "покоцать"
delete from _1soper (nolock)
where docid not in (select iddoc from _1sjourn (nolock))
-- проверка правильности заполнения DATE_TIME_DOCID в _1sentry
-- вместо проверки - замена на правильный DATE_TIME_DOCID
update _1sentry set DATE_TIME_DOCID=_1sjourn.DATE_TIME_idDOC
from _1sjourn (nolock)
--select _1sentry.DATE_TIME_DOCID,_1sjourn.DATE_TIME_idDOC
from _1sentry (nolock), _1sjourn (nolock)
where _1sentry.DOCID=_1sjourn.idDOC and
_1sentry.DATE_TIME_DOCID<>_1sjourn.DATE_TIME_idDOC
-- проверка базы - можно раскомментировать
--dbcc checkdb
-- переиндексация базы данных - можно раскомментировать
--exec _1sp_dbreindex
Запускать этот скрипт лучше всего на копии базы – мало ли что. Важное замечание – если с помощью скрипта удаляются проводки по операции, то восстановить их потом будет очень трудно, в то время как удаление проводок по документам не так страшно (их всегда можно перепровести).
Вот и все. Пишите мне, если у вас есть свои методы борьбы с описанными ситуациями – пополним наш арсенал вашим оружием!
Удачной борьбы с потерянными проводками и повторяющимся ключам – глюками 1С!
(1)Произвести ТИ ( тестирование и исправление базы данных)
еще как вариант загрузить в SQL и DBCC CHECKTABLE (_UsersWorkHistory, repair_allow_data_loss)
Я же написал, что ТИ делал, оно ничего не дало.
(5)_UsersWorkHistory - таблица истории работы пользователя.
DBCC CHECKTABLE Производит проверку целостности всех страниц и структур, составляющих таблицу или индексированное представление.
REPAIR_ALLOW_DATA_LOSS
Пытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.
"Если необходимо использовать аргумент REPAIR, выполните инструкцию DBCC CHECKTABLE без параметра восстановления, чтобы узнать требуемый уровень восстановления. При использовании уровня REPAIR_ALLOW_DATA_LOSS рекомендуется создать резервную копию базы данных перед выполнением инструкции DBCC CHECKTABLE с этим параметром."
Пытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.
Частичная потеря данных может привести к более серьезным ошибкам?
Насколько я понимаю из названия таблицы, это просто история работы пользователей.
Если какой-то шаг работы пользователя сотрется - это же ни на что не влияет.
Но важно знать, что за пользователь был, возможно, у него связь с базой плохая или он оставляет базу открытой на неск.дней. Надо выявлять и вразумлять таких пользователей.
Так что мне интересна более полная информация об ошибке.
Или такая команда молча все выполнит?
(7)
Не факт что вы установите кто пользователь!
"Если необходимо использовать аргумент REPAIR, выполните инструкцию DBCC CHECKTABLE без параметра восстановления, чтобы узнать требуемый уровень восстановления. При использовании уровня REPAIR_ALLOW_DATA_LOSS рекомендуется создать резервную копию базы данных перед выполнением инструкции DBCC CHECKTABLE с этим параметром."
Это DBCC CHECKTABLE (_UsersWorkHistory) надо писать?
я никогда не работал с SQL командами
Хотите заняться более глубоким анализом?
История работы пользователей
Таблица _UsersWorkHistory
_ID - Уникальный идентификатор пользователя информационной базы
_UserID - ID пользователя - владельца настройки
_URL - URL
_Date - Дата время
_URLHash - Хеш по URL
_ID - Уникальный идентификатор пользователя информационной базы;
_UserID - ID пользователя - владельца настройки;
_URL - URL;
_Date - Дата-время;
_URLHash - Хеш по URL;
_DataSeparationUse – использование разделения данных;
_Fld - общие реквизиты.
Ошибка на уникальность индексов данной таблицы возникала при попытке загрузки dt в SQL. Вылечилось загрузкой в файловую и правкой таблиц через ToolCD 1C.
Последние скачки этого инструмента относятся к версии платформы 8.3.8. Сейчас непонятно, чем пользоваться.
На текущий момент реализованы следующие
Возможности:
- получение массива таблиц БД;
- сохранение данных таблиц в файлы ("сырые" данные!);
- загрузка данных таблиц из файлов ("сырые" данные!);
- переименование таблиц, установка им новых описаний;
- создание, удаление таблиц;
- получение массива полей таблицы, подсчёт длины одной записи;
- навигация по записям таблицы, чтение/запись полей и BLOB-полей;
- сохранение/загрузка BLOB-полей в файл;
- добавление, удаление записей;
- получение примитивной информации по метаданным;
- поддержка разных целевых платформ - Windows32/64, Linux64.
Также возможна работа с базой данных (и, также, с произвольными двоичными файлами блочной структуры) на "низком" уровне: реализованы методы по чтению/записи числовых и строковых данных из блоков файла.
В общем то, суть: встретилась ошибка "Дублирование ключей в уникальном индексе '_ACCRGAT'" в самописной локальной базе. Возникла после добавления субконто к регистру бухгалтерии. Проявляется она при проведении документа, пишущего в РБ:
Перенести в серверную возможности нет.
Первое, что приходит на ум - тестирование и исправление базы. Делаем - не помогает. Можно делать с любыми настройками, эффект один и тот же.
Дальше chdbfl - он тоже сообщит, что ошибок не обнаружено.
Пробуем покопать в интернете - возможно, это я плохо ищу, конечно, но там решений, больше чем предыдущие 2 пункта нет. (есть еще варианты рыться во внутренностях таблицы в СУБД, но это не наш вариант)
Что же можно сделать:
1. _ACCRGAT - это таблица ИтогиПоСчетамССубконто, значит, попробуем пошаманить с итогами. Идем в управление итогами (Функции для технического специалиста -> Стандартные -> Управление итогами) и переходим в Полные возможности:
2. Видим, что для Регистра используются Итоги и Текущие итоги:
3. Что ж, попробуем их отключить и включить снова: Сверху жмем на "Итоги" -> "Выключить использование итогов", и так же на "Текущие итоги" -> "Выключить использование текущих итогов".
4. Казалось бы, выключили, теперь, чтобы все работало как раньше надо включить ("А вы пробовали выключить и включить?") - Включаем, пробуем провести документ - ошибка сохраняется.
5. Фокус тут в том, что нужно Выключить использование итогов, затем провести хотя бы один документ, а только после этого включить их обратно. После этого ошибка пропадает, и другие документы пишутся корректно.
Понятно, что ошибка довольно специфичная, но может, благодаря этой статье кто-то сможет с ней разобраться быстрее.
От простой для отдельных компаний до комплексной автоматизации крупных холдингов.
Любая из конфигураций 1С может выдать ошибку:
Она может возникнуть при работе в режиме управляемого приложения, при открытии формы выбора, списка или установлении отбора в такой форме. Т.е. программа использует запрос в динамическом списке, а при переносе из-за сбоя программы могут появиться дублирующие строки, т.е. в списке будут содержаться одинаковые ссылки на справочник или регистр. Например, при установлении отбора в справочнике «Сотрудники». В результате и появляется такого рода ошибка.
Рис.2 Ошибка в справочнике «Сотрудники»
Например, в ситуации со справочником «Сотрудников» рекомендуется проверить регистры текущих сведений (кадровые данные и тарифная ставка), чтобы в них не было дублей по одному и тому же работнику, и регистр «Основные сотрудники», чтобы не было физлиц с незаполненными сведениями. Здесь могут сохраниться сведения, например, когда работник был принят и когда уволен, но по каким-то причинам первая запись не удалилась, и образовались дубли. В таком случае необходимо просмотреть записи регистров и, если такая запись попадается, ее необходимо удалить (предыдущую, оставив одну последнюю), в результате чего ошибка ликвидируется.
Просмотр регистров через команду «Все функции»
Рис.3 Просмотр регистров через команду «Все функции»
Если данный раздел не доступен, то включить его можно в меню «Сервис-Параметры», установив соответствующую галочку. Открыв регистр и проанализировав данные, при обнаружении дублирующих записей их необходимо удалить.
Рис.4 Просмотр физлиц
Возникновение ошибки происходит, потому что динамические списки не поддерживают дублирование записей по ключевым полям. При работе с динамическим списком записи формируются в основную таблицу, из которой происходит динамическое считывание данных.
Поврежден заголовок файла базы данных
Повреждена таблица размещения внутреннего файла
Повреждена таблица размещения внутреннего файла
Повреждена таблица размещения внутреннего файла
Повреждена таблица размещения внутреннего файла
Повреждена таблица размещения внутреннего файла
Повреждена таблица размещения внутреннего файла
Повреждена таблица размещения внутреннего файла
Повреждена таблица размещения внутреннего файла
Повреждена таблица размещения внутреннего файла
Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_ACCUMRGT24589'
Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_ACCUMRGT24611'
Повреждены данные таблицы '_ACCUMRGT24795'. Восстановлено 3777618 из 3780974 записей.
Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_ACCUMRGT24795'
Повреждены данные таблицы '_ACCUMRGT24823'. Восстановлено 3766680 из 3770063 записей.
Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_ACCUMRGT24823'
Повреждены данные таблицы '_ACCUMRGT24901'. Восстановлено 1686797 из 1689042 записей.
Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_ACCUMRGT24901'
Повреждены данные таблицы '_ACCUMRGT24923'. Восстановлено 1685425 из 1687696 записей.
Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_ACCUMRGT24923'
Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_ACCUMRGT25356'
Повреждены данные таблицы '_ACCUMRGT25424'. Восстановлено 863054 из 863072 записей.
Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_ACCUMRGT25424'
Повреждены данные таблицы '_ACCUMRGT25597'. Восстановлено 554558 из 554612 записей.
Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_ACCUMRGT25597'
Повреждены данные таблицы '_ACCUMRGT25609'. Восстановлено 282832 из 282834 записей.
Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_ACCUMRGT25609'
Повреждены данные таблицы '_ACCUMRGT25623'. Восстановлено 53368 из 53418 записей.
Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_ACCUMRGT25623'
Повреждены данные таблицы '_ACCRG1312'. Восстановлено 1013040 из 1013208 записей.
Повреждены данные таблицы '_ACCRGAT21337'. Восстановлено 2022170 из 2022258 записей.
Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_ACCRGAT21337'
Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_ACCRGED1340'
Читайте также: