Есть две базы - ЦБ и ПБ, сильно переписанная бухия, обе крутятся на скуле. Из-за сбоя в ЦБ полностью пропало содержимое некоторых таблиц. Для экстренного восстановления пришлось выгружать содержимое этих таблиц из ПБ в текстовый файл, затем загружать в ЦБ (делалось штатными средствами SQL). Теперь при попытке загрузить файл обмена из ПБ в ЦБ вылетает следующая ошибка:

ТиИ вылетает с невосстановимой ошибкой в таблице _1SJOURN. Нагуглил, что вроде бы команда dbcc checkident должна помочь, но опасаюсь, не отразится ли это на последующих обменах. Можно было бы попытаться удалить проблемные записи непосредственно из таблиц, но не очень понятно, как их определить. Можно,конечно, из файла обмена убрать проблемные документы, но это, разумеется, вовсе не вариант.
Кто сталкивался? В какую сторону копать?
---
В наборе инструментов MS SQL есть такая замечательная штука, как Profiler. Он покажет, какой последний INSERT уходил на сервер. Отсюда уже можно копать.
---
Можно было бы попытаться удалить проблемные записи непосредственно из таблиц, но не очень понятно, как их определить.
Может пригодится ? http://www.1csql.ru/materials/articles/admin.html - в первой статье про повторяющиеся ключи (duplicate key) пример простого запроса.
---
Я бы думал как из периферийной БД сделать центральную БД, а потом заново создать периферийную, благо, как из периферийной сделать основную информации хватает...
---
Sergius79, уже думал над этим. Но мне не улыбается сначала удаленно прокачивать с одного сервера на другой порядка 25 гигов, а потом еще перетаскивать в нее с ЦБ документы, набитые с последнего обмена. Это, в конце концов, займет много времени, а максимальный срок незанятости баз, когда с ними никто не работает - примерно 12 часов.
---
DH таблицы, это таблицы документов, а они регистрируются в таблицах обмена, и маловероятно что их безболезненно можно перетащить из ПБ в ЦБ, потому как в журнале документов _1SJOURN их разное количество зарегитрировано, вероятно вылезут еще ошибки...
---
Правильно ли я понимаю, что некоторые таблицы были просто взяты из периферийной базы и перенесены в центральную вместе со всем содержимым?

Но таблицы упавшие я бы поднимал с пусть и устаревшей немного, но с резервной копии ЦБ. (Надеюсь она то есть?)

Может лучше их обнулить, т.е. удалить все строки и пометить документы из них к обмену, чтобы они обменов в ЦБ "приехали".

Хотя коль такая авария случилась, то все равно базы нужно рядом держать и сводить до кучи вручную. Данная же ошибка похоже из-за того, что документ который помечен как вновь созданный уже с таким ключем есть в ЦБ, чего при нормальном обмене произойти не могло.
Если таких доков не много (которые были добавлены после последнего удачного обмена ) можно попробовать их вычистить вручную в таблице _1SJOURN . Возможно все будет ОК.
---
n_kremko, Может лучше их обнулить, т.е. удалить все строки и пометить документы из них к обмену, чтобы они обменов в ЦБ "приехали".Не уверен, что это хороший вариант. Ведь ссылки на эти документы в _1SJOURN никуда не денутся, следовательно, снова возникнет ошибка.Если таких доков не много (которые были добавлены после последнего удачного обмена ) можно попробовать их вычистить вручную в таблице _1SJOURN . Возможно все будет ОК.Их действительно немного (~50 штук), т.е. почистить реально. Вопрос - как найти в таблице эти самые документы.Данная же ошибка похоже из-за того, что документ который помечен как вновь созданный уже с таким ключем есть в ЦБ, чего при нормальном обмене произойти не могло.В структуре файла обмена не нашел признака создания документа. Если бы нашел, просто убрал бы этот признак, и документ, надеюсь, записался бы как измененный.

(6) Pari, Может пригодится ? http://www.1csql.ru/materials/articles/admin.html Спасибо, я видел эту статью. Трабла в том, что ключи дублируются не в самой базе, а в базе и файле обмена. Т.е. нужно сравнивать данные в базе и данные в файле обмена ((
---
а тестирование и исправление ИБ что сказало? Или ты сразу принялся лепить таблицы из периферийной?
---
Для экстренного восстановления пришлось выгружать содержимое этих таблиц из ПБ в текстовый файл, затем загружать в ЦБ (делалось штатными средствами SQL).
Но тут ведь ничего страшного - восстанавливаете бэкап, который сделали перед этой операцией, и не торопясь разбираетесь в изначальной проблеме?
---
Соглашусь с Sergius79 - Вы средствами самой 1с пытались провести тестирование данных??

команда которую Вы нагуглили не проверяет данные 1С - она проверяет целостность скульных данных. Да в нем хранится база, но этой командой она не тестируется.

если в папке базы есть папка с именем типа "new stru" нет ли там текстовика с описанием изменений? возможно что-то "покрутили" в конфигурации.
---
rivz, а каким образом ТиИ поможет, если из центральной в распределенку пытается записаться документ, который там уже есть (благодаря искусному владению средствами SQL)?
---
В наборе инструментов MS SQL есть такая замечательная штука, как Profiler. Он покажет, какой последний INSERT уходил на сервер. Отсюда уже можно копать.
---
Спасибо все принявшим участие в обсуждении, вопрос решен. К сожалению, ни один из способов не пригодился, поэтому деньги отдаю ADirks'у.
---
MaxDavid, а как в итоге решен вопрос то был? :)