Доброго вечера.
Есть база 1с77 Компл, нетиповая. К ней прикручен МОД, в данный момент настраиваем периферийку для филиала. Было предположение сделать через УРБД - сделали - заработало, но напрягает сообщение в строке состояния - "Исправление неуникальных ИДД кодов".
Что за фокус? Чем это сообщение грозит?

Уточню - сообщение я вижу в состоянии когда делаю обмен в конфигураторе периферийной базы.

УРБД + МОД    :-)))

Переходите на восьмерку, там это реализовано

(2)Я тоже от смеха обоссался, только это не решило проблему и не сняло вопроса.
(3)Дельное предложение, но боюсь сегодня не успеем. Без 8-ки решение есть?

Ничего не путаете? УРБД слов "ИДД коды" в конфигураторе знать не может в принципе.

(0) Создаются новые объекты без IDD от мода, который при каждой записи присваивает им эти уникальные значения.

Если МОД не используешь, то проще его деинсталировать.
А по мне - так прибить уриб и юзать МОД и ПБ сделать через МОД.

(5)Рад бы перепутать, но к сожалению нет.
Это сообщение я вижу в строке состояния когда запускаю процедуру Автообмена в конфигураторе перифирийки, по журналу регистрации видно что неуникальные коды получаются у документов "Ввод остатков", которыми я переношу остатки из центральной базы в перифирийку дополнительной обработкой.

е..ться можно, а гле-то ж спецы работу найти не могут

(6) Да - вместе их юзать непросто. Я оставил УРБД для регистрации изменений, а обмены через МОД.
ТС - правда прибей уже УРБД, пока дальше дублей не наплодил.

(9) на Кубани, ты не ANik случаем ?

(10) Был такой форум - я это.

А вообще, зачем они вместе юзаются?

(12) У ТС - не знаю. У меня осознанно.

(12) регистрация измененных объектов в МОДЕ сделана..не очень.
Уриб это делает лучше.
Ну а выгрузка и правила обменов, быстрее и проще в МОДЕ сделано.
А дальше просто - регистрируем урибом, выгружаем модо-м по мод-овским правилам

(11) я так и понял, даже помню ту тему, где ты ваял свою регистрацию..

(15) Ага - жалко семерку развивать большого смысла нет - там дальше само напрашивалось дальнейшее развите МОДа без коверканья конфы.

В принципе у меня логика обмена с перифирийной базой простая - в перифирийную базу валятся только остатки по товарам, взаиморасчеты по контрагентам и документы Перемещение (перемещение товаров на удаленный склад), а обратно все документы, которыми они регистрируют продажи (Расходная накладная, Счет фактура), кассовые движения (ПКО, РКО) и складские движения (Списание, Оприходование).
(12)С распределенкой в 77 я работал мало, поэтому решил использовать что попроще - УРБД, а тут получается что эти два механизма конфликтуют между собой...

(9)А смысл его оставлять если он дубли плодит?

(18) В Вашем случае никакого. У меня вычищен механизм регистрации МОД - используется УРБД для регистрации, как более надежный, а обмен через МОД, как более гибкий.
Т.е. через УРБД обмен не идет.

(19) А как сделано "удаление из регистрации для обмена" для несиквельных баз?

(19)Ясно, у меня происходит выгрузка остатков и необходимых документов "перемещений товаров" доп. обработками, а для заливки документов в центр. базу используется УРБД (в центр льются все документы кроме Ввода остатков, Коректировки взаиморасчетов и Перемещения - это настроено правилами обмена на закладке Миграция в конфигураторе). И кстати говоря, по поводу неуникальностей - они есть только у документов, которые я формирую доп обработкой при переносе из центральной базы, то есть документ Ввод остатков и Перемещение - по крайней мере я не обнаружил записей про неуникальность у других документов ПОКА.
Ну вот и получается, если он будет мне создавать одинаковые ИДД-шники на разные объекты ИБ, то даже для регистрации он мне бесполезен.

(20) никак.. у него скуль
:)

(22) это слишком просто :-)

(21) ибо в своих поделках ты не используешь модовские конструкции, типа ОбъектЗаписать(), заместо Записать() - отсюда и трабл с неуникальностью МОД-овского IDD.

+24 точнее, там тупо IDD вовсе не присваивается и привет.

(25) Я таки не понял - какое дело УРБД при обмене на какой -то реквизит ИДД? Я помню не подумавши УРБД на ПУБ поставил, а префиксов кодов и доков там не было, а сам ступил. Так УРБД мне спокойно дублирующиеся коды позволило закачать - потом вручную правил. А тут реквизит какой-то... Или ТС триггеров понавешал и шифруется?

(26) уриб не причем, у него тупо документы создаются своими поделками

+27 в которых он не использует модовские конструкции

(24)Хм. То есть если я буду использовать метод Провести(который успешно выполнится до конца), то подобной ошибки быть не должно, поскольку в модуле проведения уже используется конструкция ОбъектЗаписать()?

Вот кстати записи из журнала:
Исправление неуникальности ИДД = 10035520004117424
Документ.ВводОстатковТоваров ((М  )3851016)
Ввод ост. товаров 0000000014 09.02.2012 12:00:10

(26)Триггеры не трогал, если ты про скульные триггеры.
Мне вот тоже кажется, что тут какие-то нелады с УРБД-шными идд-шниками, как будто он записывает в свою upd таблицу два объекта с одним и тем же ИДД. Я пытался посмотреть в эту таблицу на скуле, но я не знаю назначение полей в этой таблице, да и хранятся они в непонятном мне виде.

+28 а сообщение (в строке состояния) про  "Исправление неуникальных ИДД кодов"
возникает при интерактивной записи таких документов, когда в модуле срабатывает ПриИзмененииМОД

(29) ёё..
МОД во все агрегатные объекты добавляет индексируемый реквизит IDD, в документах - это общий реквизит с отбором и сортировкой.
Все интерактивные действия с объектами в ПриЗаписи отправляются в ПриИзмененииМОД, в которой если у объекта отсутствует уникальный idd - он ему и присваивается + проверка его уникальности + регистрация изменений в транах.

Ежели идёт программная запись объекта, она должна быть в модовской конструкции
ОбъектЗаписать()

Всё собственнно.

(30) ТС партизан, однако :) Вам же русским языком сказали - в конфигураторе ругается при обмене УРБД - причем здесь интерактивная запись документов?

(32)
>>>>>И кстати говоря, по поводу неуникальностей - они есть только у документов, которые я формирую доп обработкой при переносе из центральной базы

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

(34) Доосваивай МОД и переходи к единообразному обмену без зоопарка.

(31)(35)Спасибо за подсказки, буду думу думать.

Подниму тему.
(36)Не успею, в понедельник филиал открывается.
(24)То есть если я буду использовать ОбъектЗаписать(), то подобных ошибок не будет? И кстати я не до конца понимаю в чем опасность этих сообщений, то есть "нутром чую, что литр, а как математически выразить не знаю".
Буду благодарен, если подскажете как дописать конструкцию ОбъектЗаписать() - пытался рисовать ОбъектЗаписать(Док.ТекущийДокумент()) - утверждает что не выбран документ, что ему туда передать то надо?

ОбъектЗаписать(Док) попробуй

(38)Пробовал - не канает. И кстати мне кажется это исправление ИДД вполне себе оправданно - ведь у меня две разные базы - откуда одна из баз знает какие ИДД назначены в другой базе? И еще, в модуле проведения уже используется данная конструкция - ОбъектЗаписать(Контекст) - разве не должна выполняться процедура ПриПроведении() при программном проведении документа?
Я вот все думаю, если у меня переназначается МОДовский идд-шник, а я использую механизм УРБД, то не похеру ли мне на этот самый ИДД-шник? Ведь если УРБД ищет документы не использует данный реквизит, то мне абсолютно по барабану его изменение - меня больше всего беспокоит задвоение и перезатирание документов.

Вроде работает конструкция ОбъектЗаписать(Док,) но в этом случае валится метод Док.Провести(), который вызывается сразу после ОбъектЗаписать - говорит, мол, "Данная операция недоступна при проведении документа!".

Если кому-то поможет, то во первых, эти два метода надо поменят местами :), а во вторых надо корректно назначить правила миграции для констант, их там до *опы.