Уважаемые гуру подскажите почему код:
Функция ДайРОдителяМАТ(ОлеРод,Вид)
   СпрМ=СоздатьОбъект("Справочник."+Вид);
   //СпрМ=СоздатьОбъект("Справочник.Контрагенты");
   Если СпрМ.НайтиПоНаименованию(ОлеРод.Наименование,0,1)=1 Тогда
       Если СпрМ.ЭтоГруппа()=1 Тогда
           Возврат СпрМ.ТекущийЭлемент();
       КонецЕсли;
   КонецЕсли;
   СпрМ.НоваяГруппа();
   СпрМ.УстановитьНовыйКод("Гр");
   СпрМ.Наименование=ОлеРод.Наименование;
   СпрМ.Записать();
   Если ОлеРод.Родитель.ВЫбран()=1 Тогда
       СпрМ.Родитель=ДайРОдителяМАТ(ОлеРод.Родитель,Вид);
   КонецЕсли;
   //    Сообщить("Записана новая группа "+СпрМ.Наименование);
   Трассировка("Записана Группа "+СпрМ.Вид()+" "+СпрМ.Наименование);
   СпрМ.Записать();
   Возврат СпрМ.ТекущийЭлемент();
КонецФункции

на строчке    СпрМ.Записать();
Вызывает исключение?

если в ОлеРод элемент, то зачем смотреть наименование ?

забыл добавить... это перенос справочника через оле... и ОлеРод это ссылка на олемент в базе присоедененной через Оле-соеденение

и да ошибка выходат на строчке СпрМ.Записать(); после трассировки

СпрМ - локальная переменная

(3) Ты дурак, или прикидываешься?
Абсолютно правильно тебе система говорит.
ИМХО, я бы кодировал по внутренним идентификаторам в БД.
Або они стопудово уникальны.

(3) обоснуй

(5) как ты предлагаеш организовывать поиск по внутреннему идентификатору....?

(5) в прочем смысл твоей фразы полный бред

(7) Ты знаешь как клюшки хранят ссылки?
(8) Это твой код ошибочен, ибо мозг включать лень - легче на форуме спросить.

(9) согласен мозг уже тупит.... хотел услышать мнение общества... а тут только оскобления и ни грамма конструктивной информации

и.... эээ....  что есть клюшки? простите мою неграмотность

(8) К тому же, а с чего это наименование вдруг стало уникальным?

(12) похоже не только я туплю. Вопрос не про нименование. А про то что почему, после вызова метода СпрМ.УстановитьНовыйКод("Гр"); возвращается ошибка "код не уникальный"

(10) Смотри: клюшки=1С 77, далее, уникальность, в принципе, в рамках 77 лучше рассматривать на уровне внутренних идетификаторов, это поле "ИД" в физических таблицах, для импорта разового, имеет смысл создать рекизит ИД77 и искать по нему, реквизит же можно получить используя ЗначениеВСтрокуВнутр, переводя число через недокументированныую функцию 77 перобразования числа из 10 в 36 кажись можно получить идентификатор. Всё. Важно, ИМХО, понимать,как в той, или иной системе, храниться иныормация або проблем потом будет меньше. Так что, код в (0) изначально ошибочен ибо построен на предположении, что наименование уникально, что сама по себе платформа 77 не гарантирует, стало быть надо опираться на то, что стопудово будет обозначать одназначно требуемый объект. Как-то так. Извини, не хотел обидеть.

(13) уникальность в пределах подчинения в твоем справочнике.

(13) Банально, системе не хватает либо длины кода, либо код - число.

(14) Не хочу обидеть, но у него один и тот-же элемент справочника, с одним и тем-же кодом записывается два раза, и ошибку выдает только на второй записи.

(15) То же верно.

(16)
   СпрМ.Записать(); //заметьте, записали успешно.
   Если ОлеРод.Родитель.ВЫбран()=1 Тогда
       СпрМ.Родитель=ДайРОдителяМАТ(ОлеРод.Родитель,Вид);
   КонецЕсли;
   //    Сообщить("Записана новая группа "+СпрМ.Наименование);

   Трассировка("Записана Группа "+СпрМ.Вид()+" "+СпрМ.Наименование);
   СпрМ.Записать(); // а вот тут выдало ошибку.

(18) В этой ветке что-то еще было верно?

(17) Если искать по реквизиту, то ошибки не будет.

(17) Прямым запросом проще, ИМХО :)))
Чать не снеговикъ

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

У него только одна ошибка - он присваивает код до присваивания родителя.

(22) По-опыту, скажу, что ошибка в подходе, увы, а разовый он, или нет, не играет никакой роли, увы. Это массовые грабли, проверенные, к тому же временем.

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

(24) Разовый перенос при переходе с одной конфигурации на другую - как был разовым, так разовым и останется.

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

сорри за орфографию

(25)По-любому, сам подход ошибочен.
Видал я это, и поверь, не единожды, на примере многих баз.
Обмен должен вестись по абсолютно уникальным полям, каковыми являются ключи. Для 1С, это, в первую очередь, внутренние идентификаторы, и не важно, в 77, в 80, в 81, в 82...
Куда бы ты не переносил. Имея однозначное соответствие объект-объект ты получишь правильное отображение данных.

Так, например, используя реквизит ИДТИС можно соуществлять многопоточную загрузку в Бух.

хм.. интересно, а зачем сделан контроль уникальности в пределах подчинения...? Смысл?

(26) Если код = строка, то вам ничто не мешает в качестве кода указывать внтреннний идентификатор, согласитесь.

(28) согласен... но в данном случае это ни имеет никакого занчения. Обмен односторонний. Межде 2мя базами. Коды ручками не изменяютсяю И заводятся только в одной базе

(31)Послушайте, не имеет знаения никакого, важно понимать, кто есть источник и что уникально, если код заводится только в одной системе, то желательно и код, и сам идентификатор иметь такой же как и в источнике. Это моё, сугубо личное мнение.

(32) так оно и есть... единственное допущение сделал при создинии групп, поэтому и ввел превикс

(33) Подумайте, Сергей Вам изложил совершенно верно суть Вашей ошибке в коде, я же высказал своё мнение, что подход Ваш мне кажется не совсем верным и старался объяснить почему. Если я Вас обидел чем-либо, примите мои искренние извинения.

С уважением, Евгений.

(33) Евгений прав, если уж и синхронизируете, то по коду но никак не по наименованию.

(33) В пределах подчинения - как раз родитель и имеется в виду. То есть ошибка именно из-за этого - сначала присвойте родителя, а потом генерируйте код.

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

(37) в 77 такая возможность есть всегда.

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

Если бьются материалы в обоих базах, то в приемнике для собственных материалов сделать другой префикс.

(37) Я Вам настоятельно рекомендую немножко почитать про НСИ (Нормативно-Справочная инофрмация) и мастер-данные.
Поверьте, и позновательно, и полезно и не пожелеете затраченного времени, ИМХО.

в данном случае важна минимальная доработка типовой БД

(41) Разово добавить и удалить реквизит Вам никто не мешает, верно?

(41) Но есть же код. Наименование для этих целей подходит намного хуже. Если например потом будете вводить внутренне штрих-кодирование на базе кода - тогда сразу прочувствуете плюс. И наименование могут подправить, и вся синхронизация слетит.

(41) как сказать... занимаюсь дорабаткой не только я

(43) сего не будет

в любом случае ткая задача не ставилась... ставилась задача...."как можно дешевле"

Я Вас не понимаю, коллеги, ибо идентификатор в рамках таблицы уникален всегда, а вот код, наоименование, имеют право задвоится при обемен через УРИБ или УРБД, как Вам больше нравится, но идентификатор никогда не задвоится. Хотите верьте. Хотите -нет.

*ведроид глючит*

(47) Если запретить ручное изменение кода - то он тоже никогда не задвоится. И он тоже уникален.

у внутреннего идентификатора есть одна проблема - штатными средствами его получать достаточно долго. И его уникальность не лучше уникальности кода.

(49) Теоретически, в случае распределнной БД али конфигурации вполне возможно.
Но, обмен встанет коли идентификатор будет тот же, а место создания только центр.

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

(52) Именно. Поздравляю!
Вы выиграли грабли. Пример:
Профукали вовремя выгрузку из ТиС в Бух (вполне реальная ситуация, компания Анарион, 2003 год, осень). Объем выгрузки велик (длительность около 2 суток). Вариантов, кроме как распределить Бухию нет. Получаешь... Именно завдоение кода из-за префикса источника!

(52) Мало того, ИД - разные, Коды - разные, Наименование одно и то же. Как это Вам понравится?

(53) Не совсем понял.

(54) Задвоение кодов. Коды разные. Это как?
Так разные или одинаковые?

(55) Ну представь, профукали время, диапазон выгрузить разный в нескольких сессиях, как нечего делать, правила конвертации стандартные. Но, в разное время, поскольку разные базы и правила обмена никто не менял, задваиваются, как документы, так и элементы справочников из=за распределенности принимающих баз.

(56) Разные, базы дочерние добавляют не только префиус ИД-шнику, но и коду ибо типовая Бухия была.

(58) Ну и в чем проблема? И внутренний индефикатор так-же разный. В чем разница?

см (52) внимательно :))

(59) В том что ид состоит из 2х частей - слева 6 - это Ид в рамках базы, справа 3 - это Ид источника, значит, коли источник один нужно произвести апдейт таблиц и всё.

(61) Моя твоя не понимай. Чтоб понять что источник один - не нужен внутренний код.

(62) Верно, но мы были тогда такие же умные. Как ТС.
Без обид.

(62) Вспомнилось:
"Когда деревья, и столы, были большими" (с)

И так... по теме.
sapphire ты говориш дельные идеи... НО они не согласуются с реалиями жизни... по поводу реквизита... аля ИД я воспользовался твоим предложением.
итак... вопрос стоял не в том как оптимально построить алгоритм. А в том почему эта ошибка возникает. Дело было в уникальности кодов.(в пределах подчинения).
Так что тему можно закрывать.
P.S. Опыта у меня по более твоего....(это сапфиру).... NS спасибо за помощь... я уже говорил что утплю.. к вечеру

З.З. Ы стаж у меня более 10лет

(65) Больше не утпли (а как это делается?).

(65)Ты читать не умеешь?
Все по человечески, код не уникален ;)
т.е. реквизит КОД, у группы или элемента, уже используется.
Для групп лучше использовать "свой" префикс, т.е. непохожий на префикс элементов.

(68) Прочитай ветку. С самого начала.

Уникальность кодов в пределах подчинения - зло.