Неуникальный внутренний идентификатор документов в базе #302510

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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