Доброго дня.
Конфигурация "1С:Бухгалтерия 7.7" измененная типовая по MS SQL Server 2000 (SP3).
После тестирования и исправления базы с реиндексацией, проверкой логической целостности, пересчетом служебных данных, пересчетом итогов – база не грузится в монопольном режиме и выдает следующую ошибку:
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 ‘ 5NLX ’
SQL State: 01000
Native: 3621
Message: [Microsoft][ODBC SQL Server Driver][SQL Server] The statement has been terminated.
После ручного удаления повторяющихся ключей из таблицы _1SCRDOC и последующего тестирования и исправления базы ситуация с ошибкой повторяется.
Не помогает также полное удаление записей из таблицы _1SCRDOC с последующих тестированием и исправлением базы.
Вопрос как бороться с повторяющимися ключами и из-за чего они могут возникать?

ФАК, конечно, мы проигнорировали...

Из _1SCRDOC удалять строки, нарушающие уникальность индекса бесполезно, так как эта таблица ссылок генерируется автоматически при пересчёте итогов. Причина данной ошибки несколько глубже.

Забыл сказать релиз 1С -25й, сложных проводок не делалось. Единственно что такая ситуация стала возникать после инсталляции МОДа на текущую базу.

To (1). Я наверное туплю но в ФАКе по 1С+SQL никакого намека на решение проблемы не нашел :(

(4)МОД здесь ни при чём...
Есть два пути, по которым можно сейчас пойти.
Путь 1. Восстанови БД на состояние, предшествующее пересчету итогов. Потом, в спокойной обстановке, решай проблему с глючными документами, которые и дают впоследствии, при создании _1SCRDOC, дублирующий индекс.
Путь 2.
Если путь 1 по каким - то причинам не подходит, то:
1. Открой dds и определи те столбцы, для которых определён уникальный индекс.
2. Определи те документы, которые глючат.
3. Что с ними делать - решай сам...

5 + Естественно, при этом предполагается, что ты умеешь работать с QA и знаком с T-SQL...

0. Удалить _1SCRDOC
------------------------
echo
1 - 17.05.05 - 13:21
была такая фигня. Проблема в следующем. В таблице _1CJournal для какого - то документа время не согласутся с временем проводок этого документа. QA пользоваться умеешь?
-------------------------
Сава
2 - 17.05.05 - 13:30
если ты про вот этот скрипт, то я его запускал
время он поменял, но пофиг - проблема не исчезла.
UPDATE _1sentry SET 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

В подобной ситуации, мне пришлост еще в 1СEntry связанную строку с 1SCRDOC убивать, потом документ с убитой строкой перепроводить...

(7)Да, действительно был такой случай. Удалять _1SCRDOC бессмысленно, так как при пересчёте итогов эта таблица формируется заново...

Я решил проблему следующим образом: удалил одну строчку в _1CJournal для того документа, у которого не согласуется время. При этом все итоги сохранились, а документ просто пропал из журнала документов...

(8) Только при этом надо быть на 100% уверенным, что не менялся модуль проведения документа, не то проводки будут отличаться от удалённых...

To(5): Насколько я понял из структуры таблицы _1SCRDOC поле [CHILDID] - и есть ссылка на поле [IDDOC] в таблице 1SJOURN? И если грохнуть по этим ссылкам строки в 1SJOURN по которым в _1SCRDOC дает повторяющиеся ключи то по идее проблема решится?

(12) Удали _SSCRDOC и выполни тот запрос. все!

(13) Прокоментируй, пожалуйста, зачем удалять _1SCRDOC, если при пересчете итогов эта таблица и так автоматически очищается, а потом заполняется снова. Или для тебя это открытие?