|
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 (штатно).
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |