Возможно ли реализация, с помощью внешних компонент и т.п.? Чтобы работать как с объектом?

зачем?

ВСЕГО регистра или записи?
сделай реквизит типа строка, фигачь туда вручную при записи если пустой

а чего с подчинёнными регистрами делать (коих большинство)? там регистратор обязателен

Для однозначной идентификации при автоматизированном экспорте импорте.

2(4) у тебя могут обмениваться ЧАСТЬЮ движений?
или ты настолько зануда или задачая такая, что у тебя у документа миллион движений одного регистра, и ты хочешь менять только одну? но фокус в том что перезаписываться все равно будет набор целиком

ЗначениеВСтрокуВнутр(Метаданные.РегистрыНакопления.ИмяРегистра)

GUID не должен меняться на проятжении жизни объекта. Ключ из ключевых полей в процессе жизни регистра меняется, что не позволяет однозначно его идентифицировать.

однозначная идентификация записей и так есть - набор измерений. + период у периодического + регистратор у подчинённых

2(7) whatever - все равно перезаписываться будет набор записей...

(7) Сделай реквизит типа справочник и пиши туда объект. Будет у тебя уникальное поле с гуидом.

(7) это ИМХО противоречит механизму регистров в 1с вобще

Записи. Нужно однозначно идентифицировать запись.

(12)
Вариант [B]Живой Ископаемый [/B] впринципе подходит, но на системных регистрах это вызовет ошибку обновления.

2(13) что за системные регистры? что за ошибку обновления?

Живой Ископаемый

(4) Если ты собрался меняться объектами по ГУИДу между базами, то одного ГУИДа для однозначной идентификации мало, нужно ГУИД + КлючИБ (2 реквизита). ГУИД уникален только в пределах ИБ.

если ты назовешь этот реквизит
"оченьДуракцийПрефиксТакойКОторый1СНикогдаНеДогадаетсяИспользоватьУИД" и сделаешь подписку, то любые обновления пройдут гладка даже без необходимости лазить внтурь

2(16) не говорите глупостей. Он же этот уид будет и передавать

(16) при обменах гуид уникален во всех базах, как же бы обмениволось по разным гуидам

(8)
В этом случае ключ может меняться в процессе жизни объекта.

(16) ИБ достижимо, недостижим GUID.

понятно... поговорить надо было...

какая чушь

(17), (18) если между сеансами обмена и в базе-источнике, и в базе-приемнике появилось по новому объекту и по случайному совпадению ГУИДы их совпали - при обмене объект из базы-приемника затрется.
И не будет никаким чудесным образом контролироваться, что ГУИД в ИБ уникален для всех 1с-ных баз вообще.. =) Это просто уникальный внутри базы данных ключ 32 байта, не более того.

+22. как можно говорить относительно НЕ ОБЪКТНОЙ сущности "работать как с объектом", мож лучше в повара пойти пока есть время для развития)

2(23) это ваше случайно совпадение произойдет ближе к концу нашей Вселенной.

(23) >и по случайному совпадению ГУИДы их совпали
вероятность этого равна 0,0000[стопитцот нулей]1. Имхо

при чем еще эти объект будут и одинакового типа.. самой не смешно?

(19) в 1С нет жизни объекта регистра. Потому что запись регистра изменить невозможно. Только один путь используется: удаляется старая запись и формируется новая, при любом изменении регистра.

+(28) при чем набором целиком, а не одной записью. вроде бы

(29) для непериодических независимых - по одной записи, даже обмены по одной записи ходят. для зависимых - набор

2(30) ну это понятно

(25), (26) да мне чего, меняйтесь хоть по коду, он в пределах справочника жешь тоже уникален ;)
(24) + 100.
Смысл меняться отдельными записями РС - не понятен.
Нет, у меня был клиент, где был крайне кривой учет и РС с миллионами записей, не подчиненный регистратору. Каждая запись описывала мероприятие (например, телефонный звонок). Баз было 60, записей в каждой было много, записей в центральной - очень много.
Построено все было так, что набор ключевых полей у существующей записи можно было "поменять", как пишет (7). Ну там контактное лицо могло поменяться, или период..
Обмен проводили тоже по "ГУИДам", только "архитекторы" системы поскупились на 36 символов и оставили из них 30, кажется.. По непонятным мне причинам. Первые несколько лет все было хорошо. А потом эти "недогуиды" стали совпадать и записи затираться.
Это так, к вопросу о вероятностях... ;)

А если серьезно, в случае моего клиента, изначально была выбрана 100% неверная архитектура. РС был абсолютно неэффективен. Но мы сейчас не это обсуждаем, кажется ;)

(32) Если ты будешь несколько баз объединять, тоже будет уникален?

"на 36 символов и оставили из них 30" пффф...

количество времени затрачиваемое на брутфорс пароля растет экспоненциально от количества символов в пароле

(0) Открой БД и посмотри, как физически выглядит таблица любого регистра.
Там НЕТ уникального ключа, как у объектых типов. Есть только составные ключи, как писал (8). С точки зрения БД, если у записи РС "изменилось измерение" - это уже абсолютно новая запись, никак ничем не связанная со старой. Поэтому штатными средствами, без введения своего реквизита (а я настаиваю на двух реквизитах) - ничего у тебя не получится.

(33) Что значит "несколько раз объединять"?
Связка ИДБазы+ГУИДОбъекта уникальна в пределах всех баз организации (где поддерживается уникальность ИДБазы). Сколько раз в каком направлении ты их не меняй.
(34) да мне не жалко, меняйтесь по ГУИДу, если Вас устраивает ответ "с некоторой вероятностью мои данные не пропадут" без обоснования расчета этой самой вероятности.

2(36) мн тоже не жалко, просто смысла ни в одном ни  двух реквизитах нет вообще никакого из-за (28),(29)

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

2(38) вы сейчас спорите с параноиком ((36) не обижайтесь :) ), худшие опасения которого оказались вовсе неиллюзорными при 30 символах... у вас заведомо проигрышная позиция... :)

(35)
>Открой БД и посмотри, как физически выглядит таблица любого регистра
Я знаю что б.д. их нет. Возможно ли добавить?
>С точки зрения БД, если у записи РС /"изменилось измерение/" - это уже абсолютно новая запись, никак ничем не связанная со старой.
Пусть так, но пусть в новой записи будет старый Guid в отдельном поле?

2(40)"Пусть так, но пусть в новой записи будет старый Guid в отдельном поле?" - это отдельная задача, которая требует отдельного сушения головы для реализации...

(40) Добавить на уровне б.д. чтобы 1с не сочла за изменение конфигурации?

для подчиненных регистров - у записи первичный ключ - регистратор + номер строки,
для неподчиненных - комбинация значений измерений с галкой "основной отбор"

2(42) это парнуха по трем причинам а) это нарушение лиц. соглашения
б) если вдруг придет обновление которое реструктуризует таблицу, это изменение уплывет
в) почему вообще стоит такая задача?

использование GUID не более способ повысить баблоемкость разработки и сопровождения, намутить так чтобы потом руководсву было видно - попытка сменить работника закончится ещё большими расходами

(39) я в свое время тоже так говорила своему начальнику.. =)) Он мне тогда рассказал одну историю.
Работал он в одной конторе, там сисадмином был старый военный. И он, как человек старой закалки, все операции дублировал и делал по 3 раза. 3 копии всего, 3 бекапа. Над ним много лет все смеялись и подшучивали, пока в один чудесный день не случилось так, что данные были потеряны, первый бекап испорчен, второй бекап испорчен, а третий - спас ситуацию.
И в той конктретной ситуации очень хорошо, что админ оказался-таки "параноиком".

Я в который раз повторюсь, что ни на чем не настаиваю. =)
В моем случае, когда у меня была связка "ГУИД + ИДбазы" мне было просто полезно знать, из какой базы ко мне пришел объект. Это, кажется, даже было измерением регистра, и в том конкретном случае оказалось более чем оправдано.

(40) ну вот ты сам и пришел к тому, что НУЖНО добавлять в регистр свой реквизит-"уникальный ключ записи". По-другому никак не получится.
Так добавляешь, или (13) и (20)?

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

(46) ну возьмем, например, регистр "Учетная политика". ЕСли в каждом узле у вас будет своя учетная политика, то у вас учет весь загнется. Правильно?

(48) Ну.. мне кажется, что ничего страшного, если в разных базах будет разная учетная политика.. Вопрос в том, как базы между собой связаны и чем меняются..
К чему вопрос то?

(49) ну к тому, что таких регистров несколько десятков, и в каждом будут такие проблемы. Разные цены, разные договоры, всё, что должно быть одинаковым, всё будет разное. ТО есть в итоге типовую надо будет переписывать процентов на 30-40 и убирать все такие места.

у меня такое ощущение, что каждый решает какую-то свою гипотетическую задачу, причем задачи (и решения) у всех разные. =))

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

(52) контроль уникальности - отдельная тема, мы сейчас вроде не о том..
Взять РС "телефонные звонки", периодический, независимый, 1 измерение "кому звонили".
Если в базе1 позвонили Ивану Ивановичу 24.11.2011 в 12:00:00
и в базе2 тоже позвонили Ивану Ивановичу в это же самое время - это 2 разных события, или одно и то же?
А если базы захотят этой информацией обменяться - то не смогут, БД не позволит сделать вторую запись с тем же набором ключевых полей, все правильно.
Нужно либо не меняться такой информацией, либо добавлять доп. измерение.

Мне казалось, что ТС изначально спрашивал вот о чем:
Была унего в базе1 запись "Позвонили в 12:00 Ивану Ивановичу", передал он ее в базу2, а потом в базе1 запись "изменили" на "позвонили в 12:00 Петру Петровичу".
Как ему при следующем обмене понять, что Ивану Ивановичу больше не звонили и запись эту из базы2 удалить, а новую запись о звонке Петру Петровичу добавить? Это ведь абсолютно разные записи..

2(53) да, и что штатно присходит при обмене в таком случае?
просто у него вторая база не 1с похоже и с этим все трудности... ему тяжело повторить движковое поведение в8 во второй базе.

(53) Не проще ли документ "Телефнный звонок" побыстрому слабать?

(54) по ситуации 1 - не знаю, не пробовала. Либо ошибка, либо одна запись затрет другую.
На счет 2 - тоже не знаю, как фиксируются изменения: фиксируется ли где-то удаление записи РС и удаляется ли она при обмене из базы-приемника..

Для неподчиненного регистра сведений например есть _SimpleKey. Остальные включают в уникальный индекс _LineNo на него и надо ориентироваться как уникальный индекс. При этом набор сначало удаляется а потом записывается, вместо изменения,удаления и добавления тольк измененных строк. Что не является проблемой имея уникальные ключи

(56) фиксируется и удаляется

(55) Или руки уже полокоть в заднице и готовы вырезать гланды. И назад их вытаскивать уже не хочется?

(53) тупо должно быть измерение "кто звонил"

(55) Проще.
(59) не надо меня лечить, у меня нет проблемы с обменом информацией о телефонных звонках. И если бы передо мной такая задача реально стояла, то это был бы никак не РС.
Ситуация была для примера..

(58) Ну значит и ТС нет проблемы, описанной в (7). И никакой ГУИД не нужен.

(61) стандартные механизмы обмена 1с себя так ведут, а с чем он собрался синхронизировать я хз, может (54) прав и там самописка на делфи и обмениваются они хз через что)

2(61) ГУИД и не нужен.. почему нарисвался ГУИД - потому что наверное обмен идет с другой базой, и ему легче организовать синхронизацию по УИДу чем реализовывать штатный восьмерочный механизм обменов для таких регистров

(60) а звонить может "робот", одновременно по 10 телефонам Ивана Ивановича. Нужно еще одно измерение.. ;)

(64) на месте иваныча я б вас закопал при таких раскладах

(65) а нефиг было брать кредит и потом его не отдавать..
Тут, вроде, где-то была подобная тема.. ;)

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

(67) Это можно.. =)) Но робот все равно по известным номерам Ивана Ивановича будет звонить..