1с изменить гуид элемента справочника
Много баз сливают в одну. Базы делались из одной "рыбы". Т.е. был объект "Наша организация" со своим УИД. Брали Нашу Организацию и делали из нее ООО "Ромашка". Теперь эти лютики и ромашки надо слить в одну базу. И при заливке через ВыгрузкуЗагрузкуДанныхХМЛ Ромашка затирает Лютик и наоборот. Поэтому было бы хорошо в Ромашке поменять УИД заранее чтоб ничего не затереть. Делаю как поиск и замена значений, но очень уж долго работает.
Прямые запросы - нарушение соглашения. Для обменов - делается по сути , т.е. стандартная поиск и замена ссылок, Или регистр соответсвия объектов ИБ юзается. короче задача решается не таким путём как хочет автор
Лучше не УИДы меняй, а поменяй названия и прочую инфу между собой. А УИДы оставь как есть А мне все равно на соглашение, ибо база данных является моей собственностью
бывает, за 4 года 1 раз словил :) Но решение не , а опять же Поиск и замена значений. Сиречь создание нового элемента и перекидывание на него ссылок во всей базе
2 не бывает, разве только сделать так специально. А раз специально сделали - значит думали когда делали. 2 и кто же завел в двух разные объектынх таблицах записи с пересекающимися уидами и зачем он это сделал?
бывает. В разных ИБ - свой независимый генератор гуидов, пересечение их возможно в теории, но вероятность стремится к нулю
2 настолько быстро сремится к нулю, что то о чем ты описал без специальных действий ты мог словить самое ранее через миллиард лет, а не за четыре года.
когда нибудь случается в первый раз, у меня так документ по обменам бегал, в 2-х разных узлах создались одинаковые гуиды
+ вообще - одинаковые гуиды можно найти в больших РИБ базах, но очень редко попадается что они в одном виде документа-справочника
2 что разрешат? Что если поменять уид в записи, то во всех других записях уид тоже автоматом поменятся, и это будет происходить мгновенно?
Уид - это "фактически" номер объекта в его таблицы. Во всех местах, где идёт ссылка на объект, указывается этот номер. Что будет, если у какой-то записи мы поменяем "номер" - это уже будет другая запись, а от старой останутся неразрешимые ссылки, так как она будет ссылаться на номер, которого нет. То есть, даже если вам каким-то чудом удастся подменить GUID в таблице объекта, всё равно придётся запускать обработку поиска и замены значений, чтобы поменять все ссылки.
Про мгновенно никто не говорит. Но метод такой необходим. Одним общепринятым извращением станет меньше.
2 этот метод реализуем изменением уида в ведущей таблице средствами SQL и во всех ведомых. Или через поиск и замену значений. Если кто-то не знает этого или не умеет этого - то это уже его проблемы а не 1С.
> Можно ли изменить уникальный идентификатор у уже существующего элемента База 10 ГБ размером. Как ты себе это представляешь?
2 Не стали вообще. НО и создать другой элемент справочника и запустить поиск и замену значений в файловом варианте - тоже не очень долго. Если вдруг это долго, то значит либо базе давно стоит быть в клиент-серверном варианте, либо опять же, не делать вообще
из-за отсутсивя элементарного метода приходится выбирать какой изврат менее гиморен в данном случае. типично одинэсный подход)
2 бзик-бзик-бзик и есть перенести документы на новую организацию, и ТС говорит что это медленно у него.
> бзик-бзик-бзик в 1000 раз быстрее не получится так на физическом уровне. GUID - это ссылка. Это то же самое, что ты во всех таблицах документов новую ссылку пропишешь.
изменение ссылки во всех таблицах сравниваешь с полным перепроведением документов по новой организации? совесть есть?
Возможно, возможно и сопоставимо по времени, но все равно куча ненужных телодвижений, часть стандартных алгоритмов проверки документов все равно отрабатывает. Прямая замена все равно работала бы гораздо корректнее и не зря ты советуешь скуль юзать.
2 зачем она отрабатывает? потому что криворукие программисты не поставили проверку на ОбменДанными.Загрузка?
, посмотри в своей конфигурации наличие регистра сведений СоответствиеОбъектовДляОбмена. И если он есть - изучи зачем он нужен и как его использует конфигурация.
При объединении метаданных нескольких похожих, но все таки различающихся конфигураций оказалось, что некоторые идентичные объекты метаданных в разных конфигурациях имеют различные идентификаторы, что не дает возможность объединить конфигурации без потери данных. Проблема была решена использованием механизма конвертации данных.
Приблизительный алгоритм действий:
Предполагается, что конфигурации у вас уже объединены, но фактически есть их 2 версии - отличающиеся УИДом определенного объекта (в моем примере это справочник)
1. В КД создаем новые правила обмена. В качестве конфигураций источника и приемника используем одинаковую конфигурацию - любую из имеющихся двух версий
2. Создаем ПКО этого справочника (для всех реквизитов). Если для нас важно сохранить внутренние идентификаторы элементов справочника, устанавливаем галочку "Искать объект приемника по внутреннему идентификатору объекта источника". Для реквизитов ссылочного типа создаем ПКО только с полями поиска.
3. Создаем правила конвертации всех объектов информационной базы, где упоминается этот справочник (только поля поиска и реквизит с типом значения, соответствующим данному справочнику). Желательно, чтобы галочка " Искать объект приемника по внутреннему идентификатору объекта источника" тоже была установлена.
4. Создаем правила выгрузки данных для всех объектов информационной базы, где упоминается этот справочник. Сам справочник выгрузится по ссылке :).
5. Создаем резервную копию базы данных, которую планируем обновить
6. Выгружаем из обновляемой базы данные
7. Обновляем конфигурацию этой базы (файлом поставки с измененным GUID справочника)
8. Выполняем загрузку данных обратно в эту базу
Специальные предложения
Если метаданные не изменились (почти не изменились) то, возможно, удобнее воспользоваться стандартной обработкой ВыгрузкаЗагрузкаДанныхXML.
Выгружаем объекты в XML.
Загружаем измененную конфигурацию с потерей информации из объекта МД (или реквизита) с изменившимся идентификаторам.
При необходимости модифицируем файл метаданных, добавляя недостающие реквизиты. Сделать это относительно не сложно, выгружаем образец XML из свежей конфигурации, смотрим глазами и через групповую замену текста приводим структуру XML файла к новой.
//
Вариант 2. Переименовать объект МД (или реквизит) в *_OLD, обновить конфигурацию через сравнение, перебросить значение объекта МД (или реквизита), загрузить измененную конфигурацию.
1. ВыгрузкаЗагрузкаДанныхXML - сопоставляет объекты метаданных и объекты ИБ по внутреннему идентификатору. Соответственно, если при загрузке не будет найден объект метаданных со "старым" идентификатором - выдаст ошибку. Модифицировать XML файл - теоретически возможно, но надо учесть, что надо знать старый и новый GUID справочника, а также старые и новые GUID элементов этого справочника
2. как вы предлагаете перебросить значения объекта МД (или реквизита) ?
1. Обработка сопоставляет метаданные по имени, а ссылки на элементы конечно по идентификаторам.
0ccd343a-7ee1-11dd-7284-00119526ff1f
2. Написать обработку или воспользоваться УниверсальныеПодборИОбработкаОбъектов.epf
1. Обработка сопоставляет метаданные по имени, а ссылки по идентификаторам.
0ccd343a-7ee1-11dd-7284-00119526ff1f
2. Написать обработку или воспользоваться УниверсальныеПодборИОбработкаОбъектов.epf
При объединении метаданных нескольких похожих, но все таки различающихся конфигураций оказалось, что некоторые идентичные объекты метаданных в разных конфигурациях имеют различные идентификаторы, что не дает возможность объединить конфигурации без потери данных.
1. При сравнении/ объединении конфигураций, можно объекты сопоставлять.
2. Если требуется конвертация реквизита, то делается это обработку.
(3) awk,
1. при сравнении, объединении - сопоставление объектов происходит по имени объекта метаданных. при этом сопоставление можно задать вручную.
при создании файла поставки и затем обновлении конфигурации, находящейся на поддержке - сопоставление происходит только по внутреннему идентификатору. при этом при обновлении конфигурации файлом поставки (не через сравнение, объединение) - справочник "Номенклатура", например, со старым GUID будет удален, и вместо него будет добавлен такой же справочник "Номенклатура", но уже с новым GUID. Все данные в базе, связанные с этим справочником, конечно же, пропадут.
2. насчет конвертации реквизита - не совсем понял вашу мысль
Да проще все делается.
1. Переименовывается объект основной конфигурации, Номенклатура -> УдалитьНоменклатура.
2. Обновляется до конфигурации поставщика.
3. Делается обработка:
Пока Выборка.Следующий() Цикл
ОбъектЗаполнения = НайтиИлиСоздать(Выборка);
ЗаполнитьЗначенияСвойств(ОбъектЗаполнения, Выборка);
(7) awk,
я наверное туплю, поясните, что вы делаете этой обработкой ?
что я смог понять:
1. старый справочник переименовываем, обновляем конфигурацию файлом поставки, получаем в конфигурации 2 справочника - старый и новый
2. пишем обработку, которая копирует элементы справочника из старого в новый
вопросы:
1. как вы обработкой измените типы значения реквизитов других объектов ИБ, в которых есть ссылки на элементы старого справочника, а главное, как вы выполните во всех этих реквизитах замену ссылок на элементы старого справочника на ссылки на элементы нового справочника .
1. Есть такой метод НайтиСсылки.
2. Я, скорее всего, вообще не совсем понимаю модель обновления.
Вариант 1 (девелоп):
Есть три конфигурации. Вы их сливаете в одну и поставляете потребителю.
Тогда проблема старых гуидов - это надуманная проблема. Так как возникнуть она может только если клиент модифицировал конфигурацию сам. А то что он сам наделал - это уже его головная боль или ваши дополнительные деньги (какие тут три поставки?).
Вариант 2 (продакшан):
У вас есть база и вы хотите ее слить с двумя и более. Тогда зачем использовать механизм поставки? Тут скорее применение инструмента не по назначению (топором дрова рубят, а не бреются, хотя это не запрещено, но вряд ли целесообразно). В данном случае больше подойдет хранилище конфигурации, а не механизм поставки.
Вариант 3 (обновление):
Вы переходите от старой версии к новой. Тогда одно из двух либо у вас совместимые базы (бух 2.0 -> бух 3.0, вариант 3.а) либо не совместимые (бух. 1.6 -> 2.0, вариант 3.б).
Если совместимые и обновление будет проходить без конвертации, то делается как я описал с переименованием объектов и реквизитов, перебросом их на новые и последующем их удалении при очередном обновлении.
Если у вас несовместимые конфигурации, то очевидно что будет выгрузка/конвертация/загрузка всей базы.
Так что способ в вашей статье я могу отнести только к 3.а или к 3.б, поскольку считаю вас квалифицированным специалистом, который не будет бриться топором (вариант 2) или не соблюдать правила при доработке типовых конфигураций у клиента (вариант 1). А так же знает, что конфигурация 1 + конфигурация 2 = конфигурация 3, но не как ни конфигурация 12 или конфигурация 21.
В принципе статью нужно было бы начинать с объяснения того, как можно объединить продукты, что в результате получится, как при этом перенести/сохранить данные. Было бы очень познавательно, особенно для новичков.
(9) awk,
ок, поясню немного ту ситуацию, с которой столкнулся я и для которой было выработано данное решение.
в организации было порядка 8 вариантов конфигураций бухгалтерских баз, основанных на одной конфигурации "Бухгалтерия для Украины". все эти конфигурации обновлялись и дорабатывались независимо, пока мне это не надоело и я не объединил их конфигурации в одну.
собственно, так и было выработано решение - выгрузить/загрузить данные через КД. иных вариантов я до сих пор не вижу. кстати, как мне мог бы помочь метод НайтиСсылки ? он может изменить тип значения реквизита объекта ?
по вашей классификации, можно считать, что у меня были 2 несовместимые конфигурации
(10) vdscom,
1. А зачем файл поставки? Если можно просто подключать и обновлять напрямую с хранилища?
2.
Есть Конфигурация 1 (КФ 1) и Конфигурация 2 (КФ 2)
Допустим Контрагенты КФ1 <> Контрагенты КФ2.
Берем КФ1 преименовываем справочник Контрагенты в кф1Контрагенты
Преименовываем рекфизиты с типом Контрагенты в кф1Контрагент, кф1Грузополучатель и т.д.
Обработка позволяет при использовании MSSQL в качестве СУБД поменять GUID объекта. Внимание. Данная обработка обращается к СУБД «напрямую», используйте ее на свой страх и риск. Используйте обработку только в случае, если вы четко понимаете, что и для чего вы делаете. Я всех предупредил.
При использовании распределенных БД часто возникает проблема «Задвоения» элементов или наоборот, «Объект не найден».
Данная обработка позволит вам установить произвольный GUID для существующих объектов.
При замене GUID объекта обработка изменяет GUID по ссылкам во всех связанных объектах.
Принцип работы с обработкой:
1) В поле «Элемент» указываем объект базы, у которого мы хотим поменять GUID.
Поле «Тек ГУИД» заполняется GUID-ом выбранного элемента.
2) В поле «Нов ГУИД» вводим GUID который мы хотим задать для этого элемента.
3) Указываем строку подключения для базы данных.
Важно. Поскольку обработка происходит на сервере, то строки подключения различаются для х64 и х32 сервера приложений.
4) Тип алгоритма:
"Медленная" замена, с отображением таблиц – При поиске на каждый подходящий реквизит выполняется 3 запроса к MS SQL серверу, при этом выводится информация о таблицах и количествах замены.
Быстрая замена – замена всех значений происходит хранимой процедурой, за одно обращение к MS SQL серверу, однако таблицы для замены определяются при помощи «НайтиПоСсылкам». (Быстрее первого способа, но минимум информации)
Быстрая замена, везде, включая движения документа– замена всех значений происходит хранимой процедурой, за одно обращение к MS SQL серверу. В процессе замены мы пытаемся заменить ссылку в любом подходящем по типу поле в БД. Таким образом, ссылки будут замещаться и в движениях документов и в итогах.
Самый опасный способ! Но мы ведь смелые, без бэкапов ощущения не те (сарказм).
В этом случае желательно сделать тестирование и полный пересчет итогов. А в случае режима «слияния» объектов пересчет вообще обязателен.
5) Для современных релизов платформы у пользователя, под которым осуществляется запуск обработки, необходимо в конфигураторе снять галочку "Защита от опасных действий" в противном случае 1с отказывается полноценно работать с COM-объектами.
Возможен режим «Слияния» объектов.
Предположим, у нас есть 2 элемента справочника с одинаковыми наименованиями и мы хотим, что бы это стал 1 элемент. Можно запустить обработку с поиском и заменой значений, а можно запустить мою обработку.
Выбираем 1 из элементов, «Нов GUID» делаем равным GUID-у второго элемента, отмечаем галочку «Не менять ссылку».
Таким образом во всех вхождениях первого элемента будет изменена ссылка на второй элемент, а у самого элемента GUID не поменяется после этого, помечаем к удалению первый элемент за ненадобностью.
Возможно ли вывести УникальныйИдентификатор (GUID) вместо обычной ссылки с помощью простой консоли запросов в 1С? Как должен выглядеть текст запроса? Например, чтобы получить УникальныйИдентификатор номенклатуры.
Простой 5 комментариев
Luna999, это пересказ вашего первоначального вопроса. Я вам о другом. Для чего вам этот список GUID и почему именно в консоли нужно? Может вы не по тому пути идете, решения именно вашего вопроса. Возможно вам подойдет другой подход.
Sgr_A, именно в консоли потому что для меня (пользователя) других вариантов не вижу. Для чего список - чтобы сопоставить элементы с сайтом.
Могу посоветовать использовать Инструменты разработчика от Tormozit.
После выполнения запроса нажать на кнопку (см. скриншот) и выведется GUID.
P.S. Если основной режим работы у Вас - "Управляемое приложение", просто запустите из под обычного.
На языке запросов - никак.
Однако, есть удобный набор обработок - Инструменты разработчика
В инструментах разработчика можно выводить результаты запроса с отображением гуидов ссылок и вообще в любых списках справочников и документов. Рекомендую.
Обработка позволяет при использовании MSSQL в качестве СУБД поменять GUID объекта. Внимание. Данная обработка обращается к СУБД «напрямую», используйте ее на свой страх и риск. Используйте обработку только в случае, если вы четко понимаете, что и для чего вы делаете. Я всех предупредил.
При использовании распределенных БД часто возникает проблема «Задвоения» элементов или наоборот, «Объект не найден».
Данная обработка позволит вам установить произвольный GUID для существующих объектов.
При замене GUID объекта обработка изменяет GUID по ссылкам во всех связанных объектах.
Принцип работы с обработкой:
1) В поле «Элемент» указываем объект базы, у которого мы хотим поменять GUID.
Поле «Тек ГУИД» заполняется GUID-ом выбранного элемента.
2) В поле «Нов ГУИД» вводим GUID который мы хотим задать для этого элемента.
3) Указываем строку подключения для базы данных.
Важно. Поскольку обработка происходит на сервере, то строки подключения различаются для х64 и х32 сервера приложений.
4) Тип алгоритма:
"Медленная" замена, с отображением таблиц – При поиске на каждый подходящий реквизит выполняется 3 запроса к MS SQL серверу, при этом выводится информация о таблицах и количествах замены.
Быстрая замена – замена всех значений происходит хранимой процедурой, за одно обращение к MS SQL серверу, однако таблицы для замены определяются при помощи «НайтиПоСсылкам». (Быстрее первого способа, но минимум информации)
Быстрая замена, везде, включая движения документа– замена всех значений происходит хранимой процедурой, за одно обращение к MS SQL серверу. В процессе замены мы пытаемся заменить ссылку в любом подходящем по типу поле в БД. Таким образом, ссылки будут замещаться и в движениях документов и в итогах.
Самый опасный способ! Но мы ведь смелые, без бэкапов ощущения не те (сарказм).
В этом случае желательно сделать тестирование и полный пересчет итогов. А в случае режима «слияния» объектов пересчет вообще обязателен.
5) Для современных релизов платформы у пользователя, под которым осуществляется запуск обработки, необходимо в конфигураторе снять галочку "Защита от опасных действий" в противном случае 1с отказывается полноценно работать с COM-объектами.
Возможен режим «Слияния» объектов.
Предположим, у нас есть 2 элемента справочника с одинаковыми наименованиями и мы хотим, что бы это стал 1 элемент. Можно запустить обработку с поиском и заменой значений, а можно запустить мою обработку.
Выбираем 1 из элементов, «Нов GUID» делаем равным GUID-у второго элемента, отмечаем галочку «Не менять ссылку».
Таким образом во всех вхождениях первого элемента будет изменена ссылка на второй элемент, а у самого элемента GUID не поменяется после этого, помечаем к удалению первый элемент за ненадобностью.
Читайте также: