Имя: Пароль:
1C
1C 7.7
v7: 1C 7.7 SQL испорчена базы при установке обновления.
,
0 AndZa
 
16.10.13
18:27
Имеем базу бухгалтерия 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 Тьма
 
16.10.13
18:46
Можно попробовать тупо хлопнуть табличку и выполнить ТиИ.
2 ALoHA
 
16.10.13
18:49
Выгрузка и загрузка из архива?
3 ADirks
 
16.10.13
19:36
Цитата:

Проблема такая: при обновлении конфигурации на этапе пересчёта перекрёстных ссылок 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 время было ни разу не такое, как в документе.
Но почему так получилось непонятно. После перепроведения всё стало нормально.


Только тренируйся на копии сначала.
4 МихаилМ
 
16.10.13
19:36
а если дублей будет тысячи?

напишите скрипт, который отбирает задвоенные в ВТ
  удаляет задвоенные и вставляет
уникальные с наибольшим rowid из ВТ. естественно - в транзакции
5 Злой Бобр
 
16.10.13
19:39
(0) Поднимите бекап (до обновления который), найдите там дубли и руцями посмотрите откуда ноги растут. После исправления дублей накатите обновление.
6 ADirks
 
16.10.13
19:41
и ещё по этому же поводу  http://www.1cpp.ru/forum/YaBB.pl?num=1281425103
7 Chai Nic
 
16.10.13
20:04
Помню сталкивался с этой проблемой. В 1с есть баг, описанный в (6), когда время документа в ключевом поле в _1soper пишется неправильно. Перед обновлением, которое может вызвать пересчет ссылок, следует выполнять специальный прямой запрос, который исправляет таблицы. При обычной работе этот баг не проявляется никак, только при пересчете ссылок..
8 AndZa
 
16.10.13
20:10
Коллеги спасибо!

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

(3) согласен, нельзя ли было разработчикам 1С сделать более бронебойный алгоритм.. А так ковыряться в базе скульной, редко кто сможет восстановить.
9 ADirks
 
16.10.13
20:22
(8) Если удаляли записи из crdoc - то не смертельно, но впоследствии могут быть неприятные глюки. Рекомендую синхронизировать поля DATE_TIME_DOCID во всех табличках с _1sjournal, и потом перезаполнить _1scrdoc (штатно).