Доброе время суток!

При тестировании/исправлении появилась ошибка неуникальности вн. идентификатора с предложением исправить вручную.
Посмотрев значения поля IDDOC таблицы 1SJOURN, обратил внимание, что значения идут не по-порядку.

Поэтому два вопроса:
1. Подскажите пожалуйста какой номер лучше задать для дубликата, чтобы быть уверенным, что он будет уникальным. При этом - не собъется ли номератор для дачи нового внутренного идентификатора?
2. Из-за чего возникает такая ошибка? Может есть какие-нить способы профилактики такой ошибки? (База распределенная, если это имеет значение...)

Если этот вопрос уже обсуждался ранее в форуме - прошу прощения. Буду признателен за ссылку по теме в этом случае.

Книга знаний: Получение GUID в 1С

Ребят, я понимаю, что пятница, но подскажите пожалуйста! В базе такие документы плодятся и крайне мешают.
Если этот вопрос считается слишком глупым на этом форуме - киньте ссылку где почитать про это плиз!

(0) Не правь сам руками, если не до конца представляешь себе все связи в базе. Тебе надо поправить далеко не в одном метсе...

Нет не глупым, как точно ответить я по крайней мере не знаю. УРБД смущает.
Ни чего там нештатно не шаманили?

(3) - дык сама 1с-ка просит:
"Проверка уникальности внутреннего идентификатора документов. РасходнаяНакладная. Номер PHK-.... Вн. идентификатор   L9SU2  . Исправить вручную"
А можно где-то посмотреть как править? Ведь явно же не у меня первого такая ошибка возникает...

(4) - У нас конфигурация самописная. Так что только нештатно и шаманим :)
Еще из нештатного - бывают временами отключения связи и в этом случае те соединения, которые подцеплены к серверу терминалом удаленно - отрубаются по таймауту - вполне возможно, что в это время 1с что-то делает еще.

Причем косяки такие наблюдаются на периферийной базе. В центральную передается только один из документов, которые имеют один вн. идентификатор.

Причем при поиске документа с неуникальным вн. идентификатором - он находится. А если его выбрать - курсор устанавливается на втором доке с тем же идентификатором. Может тогда строку первого документа вообще удалить в таблице журнала, а затем запустить тестирование/исправление с параметром создавать доки? Тогда 1с-ка по идее должна создать новый док уже с другим вн. идентификатором, на скока я понимаю.
Прокатит такое?

(3) Связи можно по коду найти в файлах ДБФ-ных, в общем-то. Вопрос - какой номер поставить? Может кто-нить подсказать в каком месте 1с хранит текущий (последний) номер внутреннего идентификатора, как его узнать можно?

1С хранит последний ИД документов в 1SUIDCTL.DBF
Смотри значение в поле MaxId, где поле TypeId равно 0
Присвой новый ИД с записью туда значения увеличенного на 1 (в 36-чной системе)
Потом поменяй ИД в журнале, потом DH***, DT***, потом регистры и проч.
Хорошо если доки разного вида и проведены по разным регистрам, а то еще не то наменяешь, документов то > 1 :)

(9) Спасибо за пояснения.
По регистрам, к сожалению есть и такие доки, которые проведены по одинак. регистрам. Так что пожалуй я сделаю с регистрами проще - удалю все записи с таким вн.идом, а затем запущу перепроведение проведенных доков за период. А до этого - поменяю Ид-ы на новые и запущу ТиИ, кнечна же, с опцией восстановления данных.

Есть еще одна мысль, как починить базу. Ее я и применю как только возмущение юзеров или неточность отчетов превысит предел.
Так как в центральной базе такой проблемы нет, (вернее - есть дубли записей только в таблице 1srcdoc), то самое простое убить старую периферийную базу, пересоздать ее и сделать выгрузку в нее. Тогда после вставки данные будут в регистрах и в таблицах документов корректные.

ХЕЛП!!!
Неуникальный ид доков появился и в центральной базе. Из-за этого не идет автообмен в УРБД - при попытке выгрузить документ, который имеет одинаковый ид с другим - 1с вылетает.
Причем ситуация достаточно простая - два дока с одинаковым идом одновременно указаны только в таблице 1SCRDOC. НО - очень требуется помощь - как я могу определить какая запись в этой таблице к какому из документов относится?! Неуникальный код встречается в поле CHILDID и в поле PARENTVAL, которое имеет сложную структуру.
Подскажите пожалуйста как определить к какому же из документов относится та или иная запись в этой таблице. Очень нужно!

Заранее большое спасибо!

(12) Сделай выгрузку-загрузку. В конфигураторе которая..

(13) Дак а смысл? Если в центральную базу не приходит ответ из периферии (загружать нечего) - он выгрузит опять те же самые документы (включая косячный). В периферию они загрузятся и будет та же ситуация.

удалить можно, только обоих, сделав копию того, который "высвечивается" на открываемой форме.
сначала взять ИД=ЗначениеВСтрокуВнутр(Доки.ТекущийДокумент());
и какнить так удалить:
Процедура УдалениеДока()
Док.ВыбратьДокументы(ДатаС,ДатаПо);
Пока Док.ПолучитьДокумент()=1 Цикл
ИДДок=ЗначениеВСтрокуВнутр(Док.ТекущийДокумент());    
Если СокрЛП(ИДДок)=СокрЛП(ИД) Тогда
Док.Удалить();    
КонецЕсли;    
КонецЦикла;
КонецПроцедуры

Решил по-другому. Но временное решение... Сделал ТиИ в периферийной базе и после этого выгрузка из периферийной базы пошла нормально. По крайней мере кризис это снимет. Но в центральной базе так и остались два дока с одним идом. Очень хочется это поправить. Можно просто даже убить один из доков и все ссылки на него. Но мешает то, что в вышеуказанной таблице есть ссылки на оба дока. Вот я и прошу очччень - подскажите плиз как можно определить какая из строчек к какому доку относится в этой табличке ссылок документов.
Или киньте в меня докой где можно почитать по правилам организации ссылок в 1с-ке. Буду очень признателен.

(15) Спасибо за идею! Попробую. По результатам отпишу.

(17) это не идея, с "живой" обработки выдрано... Такшо, не уодного тебя задваиваются.)))

+(15) Для удаления обоих, два раза циклом прогонять (иногда) надоть. Почему иногда=для меня тайна, так только, догады есть.

(15) В принципе - можно попробовать удалить только нужный - я же знаю и тип документа и ид его по результатам сообщения ТиИ. Лишь бы 1с-ка нашла его с помощью Док.ВыбратьДокументы(). Если этот оператор отбирает по таблице документов, а не по журналу, то есть шанс... А по журналу этот док я найти не могу.

(18) То, что с живой - обнадеживает. Очень хоцца верить, что конец моих мучений с этой заморочкой близок. Спасибо за подсказку!!!

(20) Теоретически, чисто моими глупыми размышлениями), достаточно удалить из таблички 1sjourn второй задвоенный ID, тот что "ниже" при дефолтном открытии самой таблички. В формы списков доков он не попадает, как и в выгрузки, так и индекс за него не "цепляется. А многострочный часть, записи в регистрах и прочее, скорее всего только одну ссылку IDDOC в своих телах содержат...прочем это уже надо смотреть.

(20) Возможно, если в таблице ссылок доков останутся ссылки от обоих доков, то даже и после чистки таблицы журнала в системе будет некорректное поведение... Ну, это моими глупыми размышлениями... :) Ладно, спасибо еще раз за помощь, попробую твой вариант на след. недельке и поделюсь результатами :)

(23)Че та ты чувак страдаешь с ИД номером :)...
Удали его полностью из базы... потом запусти исправление...
Он его создаст :))))
Заполни его как надо... и сделай это в тестовой версии :)

Эксперементируй :)

+(24)А возможно предется перепроводить все документы от косячного номера №1 до тек даты :)