При обновлении конфигурации 1С 7.7 поломалась база.
Ошибка: CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID %X%. Most significant primary key is ' %YYYY% '.
При входе в Конфигуратор или в режим Предприятие выдавало ошибку и прога закрывалась.
Проштудировал пару веток, в т.ч. 1C 7.7 SQL испорчена базы при установке обновления.
В итоге свел решение проблемы в один скриптик-мануал.
Может кому будет полезно.

/* 1. Выборка документов из журнала по ид. документа */
SELECT *
FROM _1sjourn
WHERE IDDoc IN (
/* Выборка записей из таблицы "Ссылки документов",
где значения 3-х полей повторяются (неуникальные записи) */
    SELECT CHILDID
    FROM _1scrdoc
    GROUP BY CHILDID, MDID, PARENTVAL
    HAVING count(*) > 1
)

/* 2. Далее по IDDOCDEF в файле 1Cv7.DDS ищем название документа. */
/* 3. В файле 1Cv7.DDS отключаем уникальность индекса таблицы _1scrdoc */
/* 4. По DOCNO ищем документы в базе и перепроводим их */
/* 5. В файле 1Cv7.DDS обратно включаем уникальность индекса таблицы _1scrdoc и запускаем 1С.
Вуаля. После пересчета все работает */

У меня оказалось 9 косячных документов "Выписка". С причиной возникновения ошибки пока не разобрался.

всего то надо truncate table _1scrdoc и пересчет служебных данных, если всё дело было только в этой табличке

не проще удалить дубли

(0) Решение этой проблемы уже было описано. Ищи в Инете.

Запрос может не выявить косячных данных, бывает необходимость в удалении индексов сначала

Проблему решил. Но все равно непонятно, что было с теми 9 выписками.
(2) (3) В _1scrdoc удалял вручную дубли. Но когда дублей уже не было 1С-ка заново пересчитывала графы отбора и перекрестные ссылки и заново писала в _1scrdoc дублирующие записи, пыталась создать уникальный индекс и опять выдавала ту же ошибку. Здесь только поиск документов, приводящих к неверному автозаполнению _1scrdoc. Ими оказались 9 выписок.

Сейчас парюсь с переводом времени из 36-ричной системы счисления в десятичную и переводом во время :)

(7) зачем ?

+8 на вот, готовые примеры..
http://www.1cpp.ru/forum/YaBB.pl?num=1153475454

(9) спс, перевел с помощью конвертера http://vanchester.ru/converter.html , а потом разложил в экселе на часы, минуты и секунды.
В общем все глючные документы имеют время EAEAY8 (в 36-ричной) или 863990000 (в десятичной) или время 23:59:59. Никаких отличий больше не нашел. Непонятно, почему 1С в _1scrdoc лепит дубли.

(10) это же баян

разные позиции доков будут в 1sjourn и в остальныз табличках, при времени 235959..где-то "время" продолжается, а где-то нет.. будет косяк в операциях и в проводках еще

(12) Позиции понятно разные при одинаковом времени. Но почему дубли в _1scrdoc?

да хз, видать найти не может по позиции и лепит еще одну запись

Ребята, продолжение истории.
После перепроведения выписок проблема решилась.
Но через некоторое время опять кажется поменял графу отбора и получил попытку создания уникального индекса по таблице ссылки документов. А там дублирующиеся записи и та же ошибка. Нашел выписки, перепровел их, база работает.
Но все равно не пойму по какой причине у меня много документов с временем 23:59:59.
И прикол 1С-ки в том, что если есть 2 дока
1. Выписка 1 23:59:59
2. Выписка 2 23:59:59
а я хочу переместить Выписку 1 под Выписка 2, чтобы учитывать движения Выписка 2, то изменение времени не перемещает документы в пределах одной секунды.

Вопрос - как установить позицию документу вручную? ПолучитьПозицию(), а установить позицию нету!

(15) в пределах секунды не получится - они будут в порядке iddoc

установить позицию: распровести, УстановитьВремя, провести

в скульной видел и 24:05 время ;)) от такое тоже бывает

Сейчас ищу документы с временем > 23:59:59.
Пока таковых нет :)

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

Если документ в реальности создан позднее (имеет больший iddoc) - значит только время менять. Если некуда - уменьшать время предыдущих документов.

(20) Тут несколько проблем в одной.
1-я: переместить документ, который в середине 23:59:59 в самый низ.
2-я: разобраться почему стало куча документов в 23:59:59.
3-я: почему строится неверная таблица ссылок документов.
Похоже все 3 проблемы связаны.

Наличие нескольких документов в одной секунде не приводит к ошибкам
Либо программист виноват либо одно из двух...

ыввы

Млин, что за глюк. Не могу пост оставить.

Короче похоже понял, почему стало много документов в 23:59:59.
Может кому будет интересно, попробую описать.
Есть документ ТоварыВПути с 2-мя табличными частями: 1-я ТЧ обычная, а вторая реализована в виде отдельного документа, данные из ТЧ которого загружаются в ТЗ основного документа. Так вот в 1 прекрасный момент кто-то поставил время любого документа в базе в 23:59:59.

После этого другой чел создал документ ТоварыВПути на рабочую дату и документ записался с текущим временем (интерактивная запись документа по умолчанию с текущим временем), а связанный отдельный документ записался со временем 23:59:59 (программная запись методом Записать() пишет не с текущем временем, а с временем посл. документа + 10 секунд). Потом наштамповали еще несколько документов ТоварыВПути с нормальным временем, но связанные документы получились в 23:59:59. Потом на след. день, меняют дату документа ТоварыВПути (может и криво, но такая логика работы) и записывают документ. Документ записывается текущим временем, а связанный документ тоже меняет дату на дату основного документа, но записывается со старым временем 23:59:59. Усугубляют положение создание документов задним число. Они пишутся все в 23:59:59, т.к. уже есть документы в это же время. Так ситуация повторяется и получается практически каждый день кот-то создает документы задним числом и все они пишутся в 23:59:59.

Выход - при программной записи связанных (имеющих цель хранить 2-ю табличную часть к основному документу) документов ВСЕГДА применять метод УстановитьВремя() и писать документы в начало дня! Я применил УстановитьВремя(0,0,1);

Буду дальше наблюдать уйдет ли проблема с "CREATE UNIQUE INDEX terminated because a duplicate key was found..." при пересчете таблицы Ссылки документов.