Ошибка SQL State: 23000 Native: 1505 #27166

Релиз 7.70.021, под SQL. Компоненты - бухгалтерия + УРБД. Конфигурация - типовая бухгалтерия, изменённая. Периферийная база УРБД, размер MDF - 2 883 072 KB, одновременных подключений каждый день порядка 5-8 чел. Проблема в следующем: невозможно войти в базу. При запуске базы задумывается над "Созданием индексов таблицы Ссылки документов" (видно в строке состояния в заставке), затем выдаёт сообщение: Message: [Microsoft][ODBC SQL Server Driver][SQL Server]CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2. Most significant primary key is '  CHW1ЭЛЛ'. SQL State: 01000 Native: 3621 Message: [Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been terminated. Накануне ночью отработало пакетное тестирование и исправление с кучей ошибок типа "Проводка номер 1 документа такого-то. Изменено время;" или "Операция документа такого-то. Изменено время;". Пакетное тестирование завершено в целом удачно (т.к. после этого оттестировалась дюжина других баз, все логи в порядке). Утром пришел на работу - база не работает. Сделал "DROP TABLE _1SCRDOC", запустил тестирование и исправление, в результате - _1SCRDOC сформирована с теми же ошибками. Итог: поднял бэк, благо он был (т.е. проблема НЕ решена). Решение данной проблемы предложено здесь: Однако: строк для "ручного" исправления СЛИШКОМ много. Удалив несколько десятков строк, я просто бросил это дело. Вопрос в следующем: что будет, если после такого ручного исправления я запущу тестирование и исправление по новой? Мне почему-то кажется, что _1SCRDOC будет опять сформирована неправильно и ситуация повторится (т.е. я для себя сделал вывод, что причина беды - неверный "пересчет служебных данных" при тестировании и исправлении, который я теперь отключил). В чём причина данной проблемы, и самое главное, как избежать? Что теперь, всегда отключать "пересчет служебных данных"? Нехорошо...

Хотелось бы услышать мнение товарисча Arhitektor...

Чтобы понять в чем дело - надо понять структуру данной таблицы. Она описана наприме в документации к ToySQL на этом же сайте. Когда будет понятна структура - тогда станет ясно откуда появляются такие записи. Сейчас мне не вспомнить точный смысл, но в этой таблице хранятся: ссылки м/у подчиненными документами, графы отбора, дополнительные журналы. Скорее всего какие-то проблемы с подчиненностью

Спасибо. Однако, все советы сводятся к "найди и вырежи ручками". Это всё хорошо, но как быть с "пересчетом служебных данных" в Конфигураторе? Всегда отключать? Некрасиво. P.S. Проблем с подчиненностью при тестировании не было. Ошибки касались только времени проводок и операций. P.P.S. Поиск по сайту "1SCRDOC" ничего не даёт.