1с изменить идентификатор формы
В новых редакциях программ 1С была существенно усовершенствована подсистема дополнительных реквизитов Дополнительные реквизиты и сведения . Эта подсистема дает возможность пользователю самим добавлять реквизиты и сведения к объектам программы не прибегая к помощи программиста.
Дополнительные реквизиты и сведения в 1С
Дополнительные реквизиты являются неотъемлемой часть справочника, хранятся в самом объекте и отображаются на его форме. С их помощью описываются свойства объекта. После их настройки они появляются на форме объекта и становятся доступны для заполнения. Они доступны тем же пользователям, которым доступен и сам объект. Дополнительные реквизиты лучше использовать для отражения общедоступной информации.
Дополнительные сведения — не видны всем, они хранятся в регистре сведений и доступны по команде из элемента справочника или документа. Они вводятся в отдельном окне Дополнительные сведения , а также в формах списков документов и справочников и могут быть доступны для просмотра пользователям, доступ которым к объекту закрыт.
Настройка подсистемы Дополнительные реквизиты и дополнительные сведения на примере 1С 8.3 Бухгалтерия 3.0
Включить возможность создавать дополнительные реквизиты и сведения и настроить их можно в разделе Администрирование — Общие настройки . Для этого в подразделе Дополнительные реквизиты и сведения установите галочки, разрешающие добавлять эти элементы.
Добавление дополнительных реквизитов
Для добавления и настройки дополнительных реквизитов в 1С 8.3 перейдем по ссылке Дополнительные реквизиты . В окне перечислены объекты, к которым можем добавить реквизиты.
Для примера, создадим несколько дополнительных реквизитов к справочнику Номенклатура . Выберем элемент, к которому будем создавать реквизит (в нашем примере Номенклатура ) и нажмем кнопку Добавить — Новый .
Для примера создадим Дополнительный реквизит , значения которого будут заданы и их необходимо будет выбрать из списка. Назовем его Доп. реквизит 1 (выбор значения) . В открывшейся форме зададим его Наименование , Тип значения оставляем Дополнительный реквизит . При желании можно установить флажок Выводить в виде гиперссылки , соответственно в форме элемента данное поле будет представлено в виде гиперссылки. Настраиваем видимость, доступность и обязательность заполнения и по желанию заполнить следующие поля.
На вкладке Значения можем перечислить значения нашего реквизита, при этом значения можно объединять в группы. Например, Значение доп. реквизита 1, значение доп. реквизита 2, значение доп. реквизита 3.
Нажимаем Записать и закрыть и также сохраняем наш созданный реквизит.
Создадим еще один реквизит, назовем его Доп. реквизит — 2 (установка галочки). Для добавления реквизита галочка, флажок установим Тип реквизита — Булево. При смене реквизита меняются настройки формы. В данном случае нам предлагается установить настройки видимости и доступности, установить всплывающую подсказку.
Сохраняем реквизит, нажав кнопку Записать и закрыть .
Введем для примера еще один реквизит с Типом значения Строка (назовем его для примера Доп. реквизит — 3 (текст)).
Все настройки интуитивно понятны.
Так, при создании дополнительных реквизитов в 1С, при выборе Тип значения реквизита, мы можем использовать разные варианты и в зависимости от его выбора немного меняется настройка создаваемого реквизита.
Итак, мы создали три дополнительных реквизита к справочнику Номенклатура .
Посмотрим, как они отобразятся в форме элемента справочника. Откроем элемент справочника Номенклатура и зайдем в раздел Дополнительные реквизиты , внизу формы.
Мы видим, три наших добавленных реквизита. В первом реквизите — поле с кнопкой выбора значений, во втором — возможность установить галочку, в третьем — обычное текстовое поле и наши всплывающие подсказки, которые прописали в настройках.
При выборе значений первого реквизита, нажав кнопку Показать все , видим введенные нами его значения дополнительного реквизита. При этом, с помощью кнопки Создать можем эти значения добавлять непосредственно при работе со справочником.
Добавление дополнительных сведений к форме
Рассмотрим пример добавления дополнительных сведений в 1С 8.3. Для этого перейдем по ссылке Дополнительные сведения , в разделе Администрирование — Общие настройки — Дополнительные реквизиты и сведения . Выберем элемент для добавления сведений и нажимаем кнопку Создать — Новое .
Новый объект в предложенный список ввести нельзя. В списке отражены все документы и часть справочников, для которых можно добавить Дополнительные сведения . Дополнительные реквизиты можно добавить лишь к справочникам.
Добавление и настройка дополнительных сведений в 1С производится аналогично дополнительным реквизитам.
Для примера создадим одно дополнительное сведение для справочника Сотрудники , где выбор будет производится из справочника Физические лица , для указания лица, которому подчиняется данный сотрудник (назовем его просто Дополнительные сведения).
Откроем справочник Сотрудники и проверим добавление сведений. Эта информация скрыта из формы элемента и открывается нажатием кнопки Еще — Дополнительные сведения .
Выбрав этот пункт, мы можем добавить дополнительные сведения для данного элемента справочника, в данном примере выбрав из справочника Физические лица .
Аналогично можно добавить Дополнительные сведения и к документам. Окно ввода дополнительных сведений также будет доступно в кнопке Еще — Дополнительные сведения документа.
Данная команда доступна как из самого документа, так и из журнала документов.
- Печать ценников в 1С
- Очистка кэш 1С 8.3
- Журнал регистрации в 1С 8.3
- Как сделать копию базы 1С 8.3
- Загрузка из Excel в 1С 8.3
- Как выгрузить документ, отчет из 1С 8.3 в Excel
Помогла статья?
Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно
Похожие публикации
-
.Налоговики утвердили дополнительные реквизиты и обновили форматы фискальных документов, обязательных..С 1 июля 2018 года действует новый ГОСТ Р 7.0.97-2016.
(4 оценок, среднее: 4,00 из 5)
Публикацию можно обсудить в комментариях ниже.
Обратите внимание!
В комментариях наши эксперты не отвечают на вопросы по программам 1С и законодательству.
Задать вопрос нашим специалистам можно в Личном кабинете
Не отвечайте, сам разобрался, вспомнил, как показывала Елена в одном из видео. Скопировал и вставил «как есть.»
Спасибо за внимание к нашему материалу.
Мы публикуем материалы по 1С Бухгалтерия 3.0 ПРОФ.
Добрый день. Хотелось бы, чтобы разобрали дальнейшие действия. Как вывести этот дополнительный реквизит справочника в форму табличной части документа, который этот справочник использует. В Еще-изменить форму — такого реквизита у справочника нет.
Здравствуйте! Необходимо открыть Ещё — изменить форму, далее установить курсор на строчку «Ссылка» нажать «Добавить поля». Откроется окно, где будут доступны в том числе и доп. реквизиты.
Не дописал про Ссылка — Добавить поля. Я там именно и смотрел. Добавленного реквизита не видно. Прилагаю скриншоты. Попробуйте воспроизвести именно со справочником Виды работ.
Создаю СКД отчет копированием изменяю его. Но настройки пересекаются. Как проще всего изменить уникальный идентификатор?
(3) Поручик,
Не помогает. 1с ка даже не открывает второй отчет, если первый уже открыт. Она считает их идентичным.
(2) echo77,
это понятно, но хочется как то проще.
(4) tolyan_ekb,
Тоже слышал про это, но что конкретно менять?
(5) Очистить кэш. Перепрописать базу в списке выбора. Открыть отчет на другой машине и сохранить его.
(6) Поручик,
Не помогло.
(7) vladir,
Спасибо, получилось. Наверное это самый быстрый и простой способ.
- сохранить форму отчета (Ctrl-C)
- очистить основную форму отчета
- удалить форму отчета
- вставить сохраненную форму (Ctrl-V)
- сделать форму отчета основной
Данные действия изменят внутренний ID формы. Сохраненные настройки привязываются к отчету по данному ID.
user1305423; admin; michmich; user855316; Tangram; volex; Somebody1; dbachinsky; _Amator_; NeviD; nikk911; TESL; SeiOkami; Vovan58; timm00; Tavalik; corbenSG; + 17 – Ответить
А если формы отчета нет и весь отчет на СКД с использованием управляемой формы компановки данных.
Как тогда поменять UID у отчета/компановки ?
(10) Serjeo, сохранить схему в старом, создать новый отчет, подгрузить схему в новый, прописать/скопировать имя.
(11) Release, Прописать / скопировать имя чего ? отчета или схемы компановки или варианта отчета(настроек) ?
(7) vladir, огромное паибо, замучался создваать отчеты копированием всех подчиненных объектов.
Этот совет работает!
(7) vladir, этот способ можно и еще сократить:
- скопировать форму отчета (F9)
- сделать новую форму отчета основной
- удалить старую форму отчета.
Самый простой способ, на мой взгляд:
1. Вставляем отчет/обработку в конфигурацию;
2. Копируем отчет/обработку в конфигурации;
3. Сохраняем новый отчет/обработку из конфигурации в файл.
user_2010; Homs; 0xana1; belmaxim; Gendelf; e-9; Lapitskiy; Летяга; SeiOkami; cargobird; + 10 – Ответить
При объединении метаданных нескольких похожих, но все таки различающихся конфигураций оказалось, что некоторые идентичные объекты метаданных в разных конфигурациях имеют различные идентификаторы, что не дает возможность объединить конфигурации без потери данных. Проблема была решена использованием механизма конвертации данных.
Приблизительный алгоритм действий:
Предполагается, что конфигурации у вас уже объединены, но фактически есть их 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Грузополучатель и т.д.
Много баз сливают в одну. Базы делались из одной "рыбы". Т.е. был объект "Наша организация" со своим УИД. Брали Нашу Организацию и делали из нее ООО "Ромашка". Теперь эти лютики и ромашки надо слить в одну базу. И при заливке через ВыгрузкуЗагрузкуДанныхХМЛ Ромашка затирает Лютик и наоборот. Поэтому было бы хорошо в Ромашке поменять УИД заранее чтоб ничего не затереть. Делаю как поиск и замена значений, но очень уж долго работает.
Прямые запросы - нарушение соглашения. Для обменов - делается по сути , т.е. стандартная поиск и замена ссылок, Или регистр соответсвия объектов ИБ юзается. короче задача решается не таким путём как хочет автор
Лучше не УИДы меняй, а поменяй названия и прочую инфу между собой. А УИДы оставь как есть А мне все равно на соглашение, ибо база данных является моей собственностью
бывает, за 4 года 1 раз словил :) Но решение не , а опять же Поиск и замена значений. Сиречь создание нового элемента и перекидывание на него ссылок во всей базе
2 не бывает, разве только сделать так специально. А раз специально сделали - значит думали когда делали. 2 и кто же завел в двух разные объектынх таблицах записи с пересекающимися уидами и зачем он это сделал?
бывает. В разных ИБ - свой независимый генератор гуидов, пересечение их возможно в теории, но вероятность стремится к нулю
2 настолько быстро сремится к нулю, что то о чем ты описал без специальных действий ты мог словить самое ранее через миллиард лет, а не за четыре года.
когда нибудь случается в первый раз, у меня так документ по обменам бегал, в 2-х разных узлах создались одинаковые гуиды
+ вообще - одинаковые гуиды можно найти в больших РИБ базах, но очень редко попадается что они в одном виде документа-справочника
2 что разрешат? Что если поменять уид в записи, то во всех других записях уид тоже автоматом поменятся, и это будет происходить мгновенно?
Уид - это "фактически" номер объекта в его таблицы. Во всех местах, где идёт ссылка на объект, указывается этот номер. Что будет, если у какой-то записи мы поменяем "номер" - это уже будет другая запись, а от старой останутся неразрешимые ссылки, так как она будет ссылаться на номер, которого нет. То есть, даже если вам каким-то чудом удастся подменить GUID в таблице объекта, всё равно придётся запускать обработку поиска и замены значений, чтобы поменять все ссылки.
Про мгновенно никто не говорит. Но метод такой необходим. Одним общепринятым извращением станет меньше.
2 этот метод реализуем изменением уида в ведущей таблице средствами SQL и во всех ведомых. Или через поиск и замену значений. Если кто-то не знает этого или не умеет этого - то это уже его проблемы а не 1С.
> Можно ли изменить уникальный идентификатор у уже существующего элемента База 10 ГБ размером. Как ты себе это представляешь?
2 Не стали вообще. НО и создать другой элемент справочника и запустить поиск и замену значений в файловом варианте - тоже не очень долго. Если вдруг это долго, то значит либо базе давно стоит быть в клиент-серверном варианте, либо опять же, не делать вообще
из-за отсутсивя элементарного метода приходится выбирать какой изврат менее гиморен в данном случае. типично одинэсный подход)
2 бзик-бзик-бзик и есть перенести документы на новую организацию, и ТС говорит что это медленно у него.
> бзик-бзик-бзик в 1000 раз быстрее не получится так на физическом уровне. GUID - это ссылка. Это то же самое, что ты во всех таблицах документов новую ссылку пропишешь.
изменение ссылки во всех таблицах сравниваешь с полным перепроведением документов по новой организации? совесть есть?
Возможно, возможно и сопоставимо по времени, но все равно куча ненужных телодвижений, часть стандартных алгоритмов проверки документов все равно отрабатывает. Прямая замена все равно работала бы гораздо корректнее и не зря ты советуешь скуль юзать.
2 зачем она отрабатывает? потому что криворукие программисты не поставили проверку на ОбменДанными.Загрузка?
, посмотри в своей конфигурации наличие регистра сведений СоответствиеОбъектовДляОбмена. И если он есть - изучи зачем он нужен и как его использует конфигурация.
Общие правила обмена объектами метаданных между конфигурациями
В процессе разработки часто возникает необходимость переноса объектов метаданных между конфигурациями. Платформа 1С:Предприятие 8 предоставляет несколько механизмов, которые в той или иной степени позволяют решать данную задачу. К ним относятся:
- Копирование объектов метаданных через буфер обмена
- Объединение конфигурации с файлом
- Загрузка конфигурации из файла
- Хранилище конфигурации
- Обновление конфигурации, находящейся на поддержке
- Обновление конфигурации базы данных
В данной статье рассматриваются некоторые особенности работы этих механизмов, которые позволяют прогнозировать результат перемещений объектов по "цепочкам" конфигураций и правильно выбирать соответствующий механизм. Следует заметить, что статья не является подробным руководством по использованию данных механизмов.
Сопоставление объектов. Имя и идентификатор объекта метаданных
При перемещении объектов между конфигурациями важную роль играет вопрос их сопоставления. Необходимо иметь возможность определить, являются ли два данных объекта разными объектами или копиями одного и того же объекта. Предположим, что мы тем или иным способом скопировали объект из одной конфигурации в другую, а затем выполнили объединение этих конфигураций. Естественно ожидать, что платформа определит соответствие двух объектов, а не будет считать их разными объектами с одинаковыми именами. Для сопоставления объектов используются имя и внутренний идентификатор объекта. И если имя в процессе перемещения объекта, как правило, не изменяется (в любом случае мы можем его контролировать и, при необходимости, модифицировать), то внутренний идентификатор объекта ведет себя по-разному в зависимости от используемого механизма. В приведенной ниже таблице описываются способы сопоставления объектов и поведение внутренних идентификаторов при использовании разных механизмов.
При отключенной возможности изменений – сопоставление по идентификаторам. При включенной возможности изменений – сопоставление по идентификаторам, которые в некоторых случаях могут отличаться. В некоторых ситуациях возможна ручная установка соответствия.
Три уровня работы механизмов
Таким образом, механизмы переноса объектов можно разделить по трем уровням:
- Механизмы которые требуют и обеспечивают строгое соответствие идентификаторов. К ним относятся сохранение / загрузка конфигурации, работа с хранилищем конфигурации, обновление конфигурации базы данных и обновление конфигурации, находящейся на поддержке при отключенной возможности изменений.
- Механизмы, которые используют соответствие по идентификаторам, но не гарантируют их неизменность. К ним относится обновление конфигурации, находящейся на поддержке при включенной возможности изменений.
- Механизмы, которые не используют и не обеспечивают неизменность идентификаторов. К ним относятся копирование через буфер обмена и объединение конфигурации.
Можно определить следующее правило:
Например, имеются две конфигурации: одна, в которой ведется разработка и вторая - в "рабочей" базе. Новые версии разрабатываемой конфигурации переносятся при помощи механизма загрузки конфигурации с последующим обновлением конфигурации базы данных. Используемый механизм переноса объектов относится к первому уровню, и идентификаторы при переносе не изменяются. Предположим, что для очередного обновления был использован механизм объединения конфигураций. Проблемы при этом не возникнет, поскольку для "старых" объектов, присутствовавших в предыдущих версиях, идентификаторы не изменились. Однако новые объекты попали в "рабочую" базу с измененными идентификаторами. Для дальнейших переносов новых версий нужно будет использовать только механизм объединения конфигураций, поскольку при выполнении загрузки (то есть при понижении уровня механизма со второго на первый), идентификаторы некоторых объектов "восстановятся" с точки зрения конфигурации разработки, но изменятся с точки зрения "рабочей" конфигурации. В этом случае при обновлении конфигурации базы данных произойдет потеря данных.
Примеры
Параллельное создание объектов
Используется одна конфигурация в двух разных базах: в базе разработки и в базе заказчика. При обновлении конфигурации заказчика, была на месте произведена доработка, в результате которой в базу был добавлен новый объект. Затем в конфигурации разработки этот объект был добавлен вручную. Фактически мы воспользовались механизмом третьего уровня (поскольку идентификаторы у объектов получились разные). Для дальнейшей синхронизации конфигураций без потери данных можно применять только объединение (механизм третьего уровня). Для того, что бы избежать подобных проблем, следует после доработки у заказчика сохранить конфигурацию в файл, а затем загрузить ее в базу разработки.
Восстановление автоматической поддержки конфигурации поставщика
Конфигурация находится на поддержке в полностью автоматическом режиме (с отключенной возможностью изменений). Предположим, что в какой-то момент возможность изменений была включена. Например, это понадобилось для срочного исправления ошибки. После исправления ошибки поставщиком, возникла необходимость отключить возможность изменений для облегчения последующих обновлений. Но это приведет к понижению уровня механизма, а следовательно гарантированного сохранения данных информационной базы при этом добиться будет невозможно. Следует создать новую базу из дистрибутива конфигурации поставщика (с выключенной возможностью изменений) и программно перенести в нее данные.
Примеры анализа цепочки изменений конфигурации
Приведем несколько примеров анализа цепочки изменений конфигурации с точки зрения возможности потери данных.
Например, конфигурация хранилища была сохранена в файл. Это механизм первого уровня. В другой базе было выполнено объединение конфигурации с этим файлом. Уровень повысился до третьего. Затем возникла необходимость подключить эту базу к хранилищу. Механизм хранилища работает на первом уровне, поэтому при этом будет возможна потеря данных.
Другой пример. Мы ведем разработку конфигурации в некоторой базе и готовим в ней файлы поставки. Кроме того, у нас есть подготовленная демонстрационная база, которую мы поставляем пользователям. После создания файла поставки очередной версии мы загружаем его в демонстрационной базе. Все использованные механизмы работают на первом уровне, поэтому расхождения идентификаторов и потери данных не произойдет.
Для получения более подробной информации по поведению идентификаторов и сопоставлению объектов, мы рекомендуем ознакомиться с циклом статей "Поставка и поддержка конфигураций".
Читайте также: