#0
by TimonXPumbA
Возможно ли реализация, с помощью внешних компонент и т.п.? Чтобы работать как с объектом?
#2
by Живой Ископаемый
ВСЕГО регистра или записи? сделай реквизит типа строка, фигачь туда вручную при записи если пустой
#3
by Maxus43
а чего с подчинёнными регистрами делать (коих большинство)? там регистратор обязателен
#5
by Живой Ископаемый
2 у тебя могут обмениваться ЧАСТЬЮ движений? или ты настолько зануда или задачая такая, что у тебя у документа миллион движений одного регистра, и ты хочешь менять только одну? но фокус в том что перезаписываться все равно будет набор целиком
#7
by TimonXPumbA
GUID не должен меняться на проятжении жизни объекта. Ключ из ключевых полей в процессе жизни регистра меняется, что не позволяет однозначно его идентифицировать.
#8
by Maxus43
однозначная идентификация записей и так есть - набор измерений. + период у периодического + регистратор у подчинённых
#10
by Beduin
Сделай реквизит типа справочник и пиши туда объект. Будет у тебя уникальное поле с гуидом.
#13
by TimonXPumbA
Вариант [B]Живой Ископаемый [/B] впринципе подходит, но на системных регистрах это вызовет ошибку обновления.
#16
by AAlexandra
Если ты собрался меняться объектами по ГУИДу между базами, то одного ГУИДа для однозначной идентификации мало, нужно ГУИД + КлючИБ (2 реквизита). ГУИД уникален только в пределах ИБ.
#17
by Живой Ископаемый
если ты назовешь этот реквизит "оченьДуракцийПрефиксТакойКОторый1СНикогдаНеДогадаетсяИспользоватьУИД" и сделаешь подписку, то любые обновления пройдут гладка даже без необходимости лазить внтурь 2 не говорите глупостей. Он же этот уид будет и передавать
#23
by AAlexandra
, если между сеансами обмена и в базе-источнике, и в базе-приемнике появилось по новому объекту и по случайному совпадению ГУИДы их совпали - при обмене объект из базы-приемника затрется. И не будет никаким чудесным образом контролироваться, что ГУИД в ИБ уникален для всех 1с-ных баз вообще.. =) Это просто уникальный внутри базы данных ключ 32 байта, не более того.
#24
by vmv
+22. как можно говорить относительно НЕ ОБЪКТНОЙ сущности "работать как с объектом", мож лучше в повара пойти пока есть время для развития)
#26
by Maxus43
>и по случайному совпадению ГУИДы их совпали вероятность этого равна 0,0000[стопитцот нулей]1. Имхо
#28
by hhhh
в 1С нет жизни объекта регистра. Потому что запись регистра изменить невозможно. Только один путь используется: удаляется старая запись и формируется новая, при любом изменении регистра.
#30
by Maxus43
для непериодических независимых - по одной записи, даже обмены по одной записи ходят. для зависимых - набор
#32
by AAlexandra
, да мне чего, меняйтесь хоть по коду, он в пределах справочника жешь тоже уникален ;) + 100. Смысл меняться отдельными записями РС - не понятен. Нет, у меня был клиент, где был крайне кривой учет и РС с миллионами записей, не подчиненный регистратору. Каждая запись описывала мероприятие (например, телефонный звонок). Баз было 60, записей в каждой было много, записей в центральной - очень много. Построено все было так, что набор ключевых полей у существующей записи можно было "поменять", как пишет . Ну там контактное лицо могло поменяться, или период.. Обмен проводили тоже по "ГУИДам", только "архитекторы" системы поскупились на 36 символов и оставили из них 30, кажется.. По непонятным мне причинам. Первые несколько лет все было хорошо. А потом эти "недогуиды" стали совпадать и записи затираться. Это так, к вопросу о вероятностях... ;) А если серьезно, в случае моего клиента, изначально была выбрана 100% неверная архитектура. РС был абсолютно неэффективен. Но мы сейчас не это обсуждаем, кажется ;)
#34
by Живой Ископаемый
"на 36 символов и оставили из них 30" пффф... количество времени затрачиваемое на брутфорс пароля растет экспоненциально от количества символов в пароле
#35
by AAlexandra
Открой БД и посмотри, как физически выглядит таблица любого регистра. Там НЕТ уникального ключа, как у объектых типов. Есть только составные ключи, как писал . С точки зрения БД, если у записи РС "изменилось измерение" - это уже абсолютно новая запись, никак ничем не связанная со старой. Поэтому штатными средствами, без введения своего реквизита (а я настаиваю на двух реквизитах) - ничего у тебя не получится.
#36
by AAlexandra
Что значит "несколько раз объединять"? Связка ИДБазы+ГУИДОбъекта уникальна в пределах всех баз организации (где поддерживается уникальность ИДБазы). Сколько раз в каком направлении ты их не меняй. да мне не жалко, меняйтесь по ГУИДу, если Вас устраивает ответ "с некоторой вероятностью мои данные не пропадут" без обоснования расчета этой самой вероятности.
#37
by Живой Ископаемый
2 мн тоже не жалко, просто смысла ни в одном ни двух реквизитах нет вообще никакого из-за ,
#38
by Maxus43
это не некоторая вероятность, это практически факт. вероятность появления такого события стремится к нулю, и нагружать базу доп реквизитами более сильный бред чем гипотетически предполагать потерю данных
#39
by Живой Ископаемый
2 вы сейчас спорите с параноиком ( не обижайтесь :) ), худшие опасения которого оказались вовсе неиллюзорными при 30 символах... у вас заведомо проигрышная позиция... :)
#40
by TimonXPumbA
>Открой БД и посмотри, как физически выглядит таблица любого регистра Я знаю что б.д. их нет. Возможно ли добавить? >С точки зрения БД, если у записи РС /"изменилось измерение/" - это уже абсолютно новая запись, никак ничем не связанная со старой. Пусть так, но пусть в новой записи будет старый Guid в отдельном поле?
#41
by Живой Ископаемый
2"Пусть так, но пусть в новой записи будет старый Guid в отдельном поле?" - это отдельная задача, которая требует отдельного сушения головы для реализации...
#43
by Fragster
для подчиненных регистров - у записи первичный ключ - регистратор + номер строки, для неподчиненных - комбинация значений измерений с галкой "основной отбор"
#44
by Живой Ископаемый
2 это парнуха по трем причинам а) это нарушение лиц. соглашения б) если вдруг придет обновление которое реструктуризует таблицу, это изменение уплывет в) почему вообще стоит такая задача?
#45
by GoldenDawn
использование GUID не более способ повысить баблоемкость разработки и сопровождения, намутить так чтобы потом руководсву было видно - попытка сменить работника закончится ещё большими расходами
#46
by AAlexandra
я в свое время тоже так говорила своему начальнику.. =)) Он мне тогда рассказал одну историю. Работал он в одной конторе, там сисадмином был старый военный. И он, как человек старой закалки, все операции дублировал и делал по 3 раза. 3 копии всего, 3 бекапа. Над ним много лет все смеялись и подшучивали, пока в один чудесный день не случилось так, что данные были потеряны, первый бекап испорчен, второй бекап испорчен, а третий - спас ситуацию. И в той конктретной ситуации очень хорошо, что админ оказался-таки "параноиком". Я в который раз повторюсь, что ни на чем не настаиваю. =) В моем случае, когда у меня была связка "ГУИД + ИДбазы" мне было просто полезно знать, из какой базы ко мне пришел объект. Это, кажется, даже было измерением регистра, и в том конкретном случае оказалось более чем оправдано. ну вот ты сам и пришел к тому, что НУЖНО добавлять в регистр свой реквизит-"уникальный ключ записи". По-другому никак не получится. Так добавляешь, или и ?
#47
by Живой Ископаемый
наоборот, пока все говорит за то, что никаких доп.уникальных ключей не нужно.
#48
by hhhh
ну возьмем, например, регистр "Учетная политика". ЕСли в каждом узле у вас будет своя учетная политика, то у вас учет весь загнется. Правильно?
#49
by AAlexandra
Ну.. мне кажется, что ничего страшного, если в разных базах будет разная учетная политика.. Вопрос в том, как базы между собой связаны и чем меняются.. К чему вопрос то?
#50
by hhhh
ну к тому, что таких регистров несколько десятков, и в каждом будут такие проблемы. Разные цены, разные договоры, всё, что должно быть одинаковым, всё будет разное. ТО есть в итоге типовую надо будет переписывать процентов на 30-40 и убирать все такие места.
#51
by AAlexandra
у меня такое ощущение, что каждый решает какую-то свою гипотетическую задачу, причем задачи (и решения) у всех разные. =))
#52
by Живой Ископаемый
а вот еще прикол - для РС учетная политика организаций мы реквизит конечно добавить можем, ага, но если например нам по обмену придет запись в которой комбинация упомянутая будет совпадать хоть с одной записью которая уже есть в базе, но у которой значение реквизита псевдоУИД будет другой, то такая запись либо а) не запишется, либо б) все равно перезапишет имеющеюся собой...
#53
by AAlexandra
контроль уникальности - отдельная тема, мы сейчас вроде не о том.. Взять РС "телефонные звонки", периодический, независимый, 1 измерение "кому звонили". Если в базе1 позвонили Ивану Ивановичу 24.11.2011 в 12:00:00 и в базе2 тоже позвонили Ивану Ивановичу в это же самое время - это 2 разных события, или одно и то же? А если базы захотят этой информацией обменяться - то не смогут, БД не позволит сделать вторую запись с тем же набором ключевых полей, все правильно. Нужно либо не меняться такой информацией, либо добавлять доп. измерение. Мне казалось, что ТС изначально спрашивал вот о чем: Была унего в базе1 запись "Позвонили в 12:00 Ивану Ивановичу", передал он ее в базу2, а потом в базе1 запись "изменили" на "позвонили в 12:00 Петру Петровичу". Как ему при следующем обмене понять, что Ивану Ивановичу больше не звонили и запись эту из базы2 удалить, а новую запись о звонке Петру Петровичу добавить? Это ведь абсолютно разные записи..
#54
by Живой Ископаемый
2 да, и что штатно присходит при обмене в таком случае? просто у него вторая база не 1с похоже и с этим все трудности... ему тяжело повторить движковое поведение в8 во второй базе.
#56
by AAlexandra
по ситуации 1 - не знаю, не пробовала. Либо ошибка, либо одна запись затрет другую. На счет 2 - тоже не знаю, как фиксируются изменения: фиксируется ли где-то удаление записи РС и удаляется ли она при обмене из базы-приемника..
#57
by Serginio1
Для неподчиненного регистра сведений например есть _SimpleKey. Остальные включают в уникальный индекс _LineNo на него и надо ориентироваться как уникальный индекс. При этом набор сначало удаляется а потом записывается, вместо изменения,удаления и добавления тольк измененных строк. Что не является проблемой имея уникальные ключи
#59
by acsent
Или руки уже полокоть в заднице и готовы вырезать гланды. И назад их вытаскивать уже не хочется?
#61
by AAlexandra
Проще. не надо меня лечить, у меня нет проблемы с обменом информацией о телефонных звонках. И если бы передо мной такая задача реально стояла, то это был бы никак не РС. Ситуация была для примера.. Ну значит и ТС нет проблемы, описанной в . И никакой ГУИД не нужен.
#62
by Maxus43
стандартные механизмы обмена 1с себя так ведут, а с чем он собрался синхронизировать я хз, может прав и там самописка на делфи и обмениваются они хз через что)
#63
by Живой Ископаемый
2 ГУИД и не нужен.. почему нарисвался ГУИД - потому что наверное обмен идет с другой базой, и ему легче организовать синхронизацию по УИДу чем реализовывать штатный восьмерочный механизм обменов для таких регистров
#64
by AAlexandra
а звонить может "робот", одновременно по 10 телефонам Ивана Ивановича. Нужно еще одно измерение.. ;)
#66
by AAlexandra
а нефиг было брать кредит и потом его не отдавать.. Тут, вроде, где-то была подобная тема.. ;)
#67
by Живой Ископаемый
а можно было взять кредит и на взятые деньги переехать в другую страну и купить другой тарифный пакет. :)
#68
by AAlexandra
Это можно.. =)) Но робот все равно по известным номерам Ивана Ивановича будет звонить..
Тэги: 1С 8
Ответить:
Комментарии доступны только авторизированным пользователям
Похожие вопросы 1С
- Отбор по реквизиту регистра в наборе записей регистра накопления
- Есть ключ записи регистра сведений. Как получить имя этого регистра?
- отчет по данным регистра накопления и регистра бухгалтерии
- Удаление записи регистра сведений в форме списка регистра
- Как сгенерировать GUID?
- В чем отличие регистра накопления от регистра сведения
- Как создать новый объект по GUID или заменить GUID
- v8: Где взять описание GUID, который в 1С 8? продолжение
- УТ 10.3. Заказ покупателя - Внутренний заказ - Резерв
- Ярлык настроек по GUID
- Получить GUID руководителя подразделения в ЗУП по GUID подразделения
- Отбор регистра на форме списка регистра сведений
В этой группе 1С
- VBA Excel: как перезаписать/перевыбрать имя файла для сохранения книги
- v7: Большая база ТиС SQL - ошибка "Недостаточно памяти" при сохранении конфы
- v7: UUID в 1С 7.7
- Программное заполнение приходного кассового ордера в 1С: БГУ 8
- v8: Не видна галка в дереве значений
- Ошибки по НДС (Экспресс-проверка)
- УФ. Динамический список. возможно ли редактирование записей в списке
- выразить строку как дату в запросе
- ГраницыЗапретаИзмененияДанных типа хранилища значений как с ним работать?
- 8.2 Не отображается иерархия элементов в СправочникСписок
- Совместное использование 1С УПП в группе компаний
- Способ списания товаров в реализации УТ 10.3
- Запрос СКД - передача значения во вложенный запрос
- Для целей учета НДС не списано....
- ЗУП: фактически отработанное время
- v7: Проблема "второго" подключения на файловой базе до 100мб
- Получение остатка из регистра накопления в 1с 8
- Конвертация данных 1С77 - 1С8
- плюсы минусы Управление небольшой фирмой ив сравнении с УТ11
- Перенос из Бухгалтерии 2.0 в Бухгалтерию 2.0