Можно ли изменить уникальный идентификатор у уже существующего элемента? #674440

Есть элемент справочника Организации можно ему сделать новый УИН как для  нового?

Только у нового можно УИД поставить. Или запросами прямыми. По сути конечно и в файловой можно, но нужно знать как

а поменять УИД между старым и Новым?

Средствами 1с нельзя

нельзя поменять у существующего уже. зачем?

Что бы значил твой вопрос?

Создать новый с заданным уидом и подменить им старый во всех ссылках на него.

Вот тебе замена ссылки у существующего

Сделай новую организацию и ссылки перебрось

Задачу объясни конкретнее, зачем тебе это надо?

Нет задачи, даже в теории чтобы надо было поменять у существующего ГУИД

Иногда это нужно, например для обмена данными, или прямых запросов, в которых завязано на УИДе

Это будет уже другой элемент, такое проканает только с не ссылочными данными

Много баз сливают в одну. Базы делались из одной "рыбы". Т.е. был объект "Наша организация" со своим УИД. Брали Нашу Организацию и делали из нее ООО "Ромашка". Теперь эти лютики и ромашки надо слить в одну базу. И при заливке через ВыгрузкуЗагрузкуДанныхХМЛ Ромашка затирает Лютик и наоборот. Поэтому было бы хорошо в Ромашке поменять УИД заранее чтоб ничего не затереть. Делаю как поиск и замена значений, но очень уж долго работает...

Прямые запросы - нарушение соглашения. Для обменов - делается по сути , т.е. стандартная поиск и замена ссылок, Или регистр соответсвия объектов ИБ юзается... короче задача решается не таким путём как хочет автор

Как насчет ситуации, когда при обмене у разных объектов совпали идентификаторы?

Лучше не УИДы меняй, а поменяй названия и прочую инфу между собой. А УИДы оставь как есть А мне все равно на соглашение, ибо база данных является моей собственностью

ну почему, сливаем данные из двух таблиц в одну - возможно Уиды совпадут

2 такого не бывает.

>>А мне все равно на соглашение нуну...

2 из каких двух таблиц?

Загрузка выгрузка идет по УИДАм

бывает, за 4 года 1 раз словил :) Но решение не , а опять же Поиск и замена значений. Сиречь создание нового элемента и перекидывание на него ссылок во всей базе

теоретически возможно даже если база не потомок

из любых ссылочных

> за 4 года 1 раз словил

Ну так что, граждане, есть выход из тунеля?

2 не бывает, разве только сделать так специально. А раз специально сделали - значит думали когда делали. 2 и кто же завел в двух разные объектынх таблицах записи с пересекающимися уидами и зачем он это сделал?

2 тебе уже сказали, что нет.

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

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

настрой загрузку/выгрузку организаций не по УИДАм ,а  по ИНН , в чем проблема то...

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

Какое-то глупое ограничение платформы тянущееся много лет, может в 9.0 все-таки разрешат.

последствия представляешь? вот автор заменит гуид - и пол базы в битых ссылках. Красота, да

Любая вероятность 50% - либо случится, либо нет. (с)

+ вообще - одинаковые гуиды можно найти в больших РИБ базах, но очень редко попадается что они в одном виде документа-справочника

2 что разрешат? Что если поменять уид в записи, то во всех других записях уид тоже автоматом поменятся, и это будет происходить мгновенно?

есть, но не такой как в . Если сливаешь по обменам - вобще проблем нет же, см

Уид - это "фактически" номер объекта в его таблицы. Во всех местах, где идёт ссылка на объект, указывается этот номер. Что будет, если у какой-то записи мы поменяем "номер" - это уже будет другая запись, а от старой останутся неразрешимые ссылки, так как она будет ссылаться на номер, которого нет. То есть, даже если вам каким-то чудом удастся подменить GUID в таблице объекта, всё равно придётся запускать обработку поиска и замены значений, чтобы поменять все ссылки.

Про мгновенно никто не говорит. Но метод такой необходим. Одним общепринятым извращением станет меньше.

2 этот метод реализуем изменением уида в ведущей таблице средствами SQL и во всех ведомых. Или через поиск и замену значений. Если кто-то не знает этого или не умеет этого - то это уже его проблемы а не 1С.

> Можно ли изменить уникальный идентификатор у уже существующего элемента База 10 ГБ размером. Как ты себе это представляешь?

Средства скл давно стали стандартными в файловом варианте?

бзик-бзик-бзик в 1000 раз быстрее чем перенести 10Гб документов на новую организацию

2 Не стали вообще. НО и создать другой элемент справочника и запустить поиск и замену значений в файловом варианте - тоже не очень долго. Если вдруг это долго, то значит либо базе давно стоит быть в клиент-серверном варианте, либо опять же, не делать вообще

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

думаю, напрямую в таблице SQL можно поменять

2 бзик-бзик-бзик и есть перенести документы на новую организацию, и ТС говорит что это медленно у него.

2 да нет, типично одинэсный подход говорить что метод которого не должно быть вообще, нужен

> бзик-бзик-бзик в 1000 раз быстрее не получится так на физическом уровне.  GUID - это ссылка. Это то же самое, что ты во всех таблицах документов новую ссылку пропишешь.

изменение ссылки во всех таблицах сравниваешь с полным перепроведением документов по новой организации? совесть есть?

2 кто сказал о полном перепроведении? ты давно заглядывал в поиск и замену значений?

напиши правила обмена или возьми с БСП

+ там есть возможность проассоцииоровать один элемент с другим

регистр соответствий

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

2 зачем она отрабатывает? потому что криворукие программисты не поставили проверку на ОбменДанными.Загрузка?

, посмотри в своей конфигурации наличие регистра сведений  СоответствиеОбъектовДляОбмена. И если он есть - изучи зачем он нужен и как его использует конфигурация.

Заменить 1 поле быстрее, чем переписывать весь объект.