Имеем базу бухгалтерия 7.7 (сильно переписанную) ~16Гб. После установки обновления мд.ника, база испортилась. (не возможно войти в конфигуратор. Т.е. симптомы как из темы (только праймари кей другой):

Ошибка SQL State: 23000 Native: 1505 - мое решение проблемы

При загрузке в монопольном режиме SQL ругается:
SQL State: 23000
Native: 1505
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 ' 26RSB '.

SQL State: 01000
Native: 3621
Message: [Microsoft][ODBC SQL Server Driver][SQL Server]The statement has ben terminated.

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

Сейчас пробуем восстановить согласно совету в ссылке. Однако уверенности что это поможет нет. Есть ли еще какие либо советы как и что можно лечить.

То что архивной базы нет (вернее архивы создавались, но они битые), это большая задница..  Самое что плохое, последняя рабочая копия это базы была в начале июля.. Это пипец..

Можно попробовать тупо хлопнуть табличку и выполнить ТиИ.

Выгрузка и загрузка из архива?

Цитата:

Проблема такая: при обновлении конфигурации на этапе пересчёта перекрёстных ссылок 1С ругается
"CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2" и умирает.
Фишка в том, что она сначала напихивает записей в _1scrdoc, а потом уже создаёт уникальный индекс,
который не желает создаваться, т.к. 1С неправильно заполнила таблицу.
Не долго думая я залез в 1Cv7.DDS, нашёл там нужный индекс (CHILDID, MDID, PARENTVAL) и вырубил ему уникальность. После повторного запуска конфигуратора обновление завершилось прекрасно.
Далее, таким вот запросом
SELECT CHILDID, MDID, PARENTVAL, count(*)
FROM _1scrdoc
GROUP BY CHILDID, MDID, PARENTVAL
HAVING count(*) > 1
SELECT *
FROM _1sjourn
WHERE IDDoc IN (
    SELECT CHILDID
    FROM _1scrdoc
    GROUP BY CHILDID, MDID, PARENTVAL
    HAVING count(*) > 1
)
определил, какие документы так жестоко ввели 1С в заблуждение (это оказались выписки). Нашёл эти
документы в 1С и перепровёл. Удалил _1scrdoc, включил уникальность обратно, зашёл в 1С - всё зашибись,
всё уникально.
Вопрос: какого фига? Небольшое исследование показало следующее: в таблице проводок по этим выпускам в
поле DocLineNo везде стояло 0, и в поле Date_Time_DocID время было ни разу не такое, как в документе.
Но почему так получилось непонятно. После перепроведения всё стало нормально.


Только тренируйся на копии сначала.

а если дублей будет тысячи?

напишите скрипт, который отбирает задвоенные в ВТ
  удаляет задвоенные и вставляет
уникальные с наибольшим rowid из ВТ. естественно - в транзакции

(0) Поднимите бекап (до обновления который), найдите там дубли и руцями посмотрите откуда ноги растут. После исправления дублей накатите обновление.

и ещё по этому же поводу  http://www.1cpp.ru/forum/YaBB.pl?num=1281425103

Помню сталкивался с этой проблемой. В 1с есть баг, описанный в (6), когда время документа в ключевом поле в _1soper пишется неправильно. Перед обновлением, которое может вызвать пересчет ссылок, следует выполнять специальный прямой запрос, который исправляет таблицы. При обычной работе этот баг не проявляется никак, только при пересчете ссылок..

Коллеги спасибо!

На данный момент с помощью идей из моей первой ссылки в первом сообщении. Мои админы дописав чуть более хитрый скрипт, который удалил ~650 дублей. База заработала. Будем проверять что в базе есть, не полетело ли чего...

(3) согласен, нельзя ли было разработчикам 1С сделать более бронебойный алгоритм.. А так ковыряться в базе скульной, редко кто сможет восстановить.

(8) Если удаляли записи из crdoc - то не смертельно, но впоследствии могут быть неприятные глюки. Рекомендую синхронизировать поля DATE_TIME_DOCID во всех табличках с _1sjournal, и потом перезаполнить _1scrdoc (штатно).