1с неразделенный объект метаданных участвует в разделенном плане обмена

Обновлено: 04.07.2024

Механизм разделения данных – относительно новая функциональная особенность 1С, отнесенная к облачным технологиям. После появления функционала компанией 1С была доработана БСП. Эти же доработки вошли в состав основанных на БСП типовые конфигурации, например, УНФ и УТ11.

Понадобилось организовать получение общих отчетов из нескольких филиалов с одинаковыми конфигурациями. Решил попробовать наработки из БСП в области разделения данных. Идея заключалась в том, чтобы загрузить данные каждого филиала в свою область данных и сформировать отчеты сразу для всех областей. Сразу скажу, что задачу решить пока не удалось, но сама попытка решения выявила проблемы и сомнительный функционал в БСП.

К статье приложена обработка, выносящая скрытый функционал операций с областями данных на отдельную форму.

В БСП предусмотрены два разделителя учета: ОбластьДанныхОсновныеДанные и ОбластьДанныхВспомогательныеДанные. Загадкой осталось, почему эти 2 разделителя ссылаются на одни и те же параметры сеанса: ОбластьДанныхЗначение, ОбластьДанныхИспользование.

Включение механизма

Если ваша самописная конфигурация основана на БСП, то, скорее всего, перед включением необходимо внедрить загадочную библиотеку "1С:Библиотека технологии сервиса". Странно, что даже Гугл не знает о таком продукте 1С. А в типовых конфигурациях процедуры ПроверитьВозможностьИспользованияКонфигурацииВМоделиСервиса в модуле РаботаВМоделиСервиса не существует. Скорее всего, найти недостающие части из этой библиотеки можно в типовых конфигурациях, выполненных на основе БСП. В частности, одна из подсистем называется СтандартныеПодсистемы > РаботаВМоделиСервиса > ВыгрузкаЗагрузкаДанных.

Механизм разделения данных включается через установку константы ИспользоватьРазделениеПоОбластямДанных. Можно установить через пункт меню Все функции.

Создание пользователей области данных

Этот пункт не обязателен, если используется вход в область данных через форму. В режиме конфигуратора создаются пользователи. Один пользователь с административными правами должен иметь во вкладке Разделение данных все неустановленные разделители данных. Для других пользователей во вкладке Разделение данных должен быть установлен разделитель Область данных основные данные. Этот разделитель должен быть явно указан в командной строке при запуске 1С.

Запуск 1С с параметром командной строки

Этот пункт не обязателен, если используется вход в область данных через форму входа.

1С можно запустить сразу в режиме разделения данных. Предусмотрен параметр командной строки /Z. Например, параметр «/Z-,+1» указывает, что 1С запускается со значением Области данных основные данные равным 1, разделитель Область данных вспомогательные данные не установлен.

Способ очень ненадежный. При запуске возникает ошибка в процедуре РаботаВМоделиСервиса. ПриПроверкеВключенияБезопасногоРежимаРазделенияДанных. Ничего лучшего, чем закомментировать эту процедуру, я не нашел. Процедура проверяет, есть ли у пользователя право менять текущую область данных, ограничены ли его права и влияет на безопасность.

Далее при запуске возникают несколько ошибок среди них: «Разделенным пользователям не может быть назначена роль Администратор системы», «Разделенным пользователям не может быть назначена роль Запуск толстого клиента».

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

Заполнить регистр сведений Области данных

Для каждой области нужно заполнить запись в регистре сведений Области Данных, присвоив областям номера и статус «Используется». Обработки могут проверять наличие записей в этом регистре перед началом выполнения.

Выгрузка данных из области

Текущая область выгружается через ОбщаяФорма. ВыгрузкаДанных. До ее использования нужно выполнить вход в нужную область данных. Форма не выведена в интерфейс пользователя в раздел Администрирование.

Данные сериализуются конфигурацией в XML-формат и запаковываются в ZIP. То есть архивирование происходит не средствами 1С-конфигуратора, как традиционная выгрузка.

Загрузить данные в область

Для появления в Администрирование-Сервис нужно через Конфигуратор в составе подсистемы НастройкаИАдминистрирование установить видимость.

Данные загружаются в выбранную область. До этого они должны быть выгружены в XML-формат.

Выводы

Опыты с входами в разные области, выгрузкой и загрузкой областей были удачными. Неудача постигла при попытке выполнить запрос получения всех организаций для всех областей данных. Ошибка: «Нельзя использовать таблицу без указания всех разделителей с независимым использованием разделяемых данных». Отчет работает по одной области, если осуществить вход в какую-нибудь область.

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

Интересно было бы узнать о хитрой задумке авторов БСП относительно общих параметров сеансов для двух разделителей, если вызов будет с параметрами: «/Z-,+1», «/Z+1,+1» и «/Z+1,-».

Использование общих реквизитов без разделения данных

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

Общие реквизиты можно разделить на два типа: используемые для разделения данных и не используемые для разделения данных. Это регулируется свойством «Разделение данных».

Назначение общих реквизитов, используемых для разделения данных, вполне очевидно. Они позволяют включить в конфигурации механизм разделения данных (multitenancy), обеспечивающий работу в одной информационной базе нескольких логически независимых или слабо зависимых областей данных.

Для чего предназначены общие реквизиты без разделения данных?

Прежде всего нужно обратить внимание на то, что не только сами общие реквизиты создаются в метаданных отдельно от прикладных объектов, в которых они используются (справочников, документов, регистров, и т.д.), но и описание включения общих реквизитов в прикладные объекты выполняется в самих общих реквизитах. Для этого используется свойство общего реквизита Состав , в котором указывается, в какие прикладные объекты включать общий реквизит. Кроме того, имеется возможность автоматического включения общего реквизита в прикладные объекты (свойство общего реквизита - Автоиспользование ). Это позволяет включать общий реквизит во все новые объекты метаданных без каких-либо действий со стороны разработчика конфигурации.

Таким образом, общие реквизиты, по сути, являются данными, добавляемыми к прикладным объектам со стороны конфигурации, а не со стороны разработки конкретного объекта. Это особенно ярко проявляется, если рассматривать жизненный цикл разработки (обновление конфигурации, доработку конфигурации при внедрении, перенос функционала между конфигурациями, и т.д.).

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

Например, может стоять задача реализации механизма создания сокращенной резервной копии данных, с наиболее критичными данными. Допустим, уже имеется некоторая конфигурация и, разумеется, желательно минимизировать изменения в самой бизнес-логике прикладных объектов конфигурации. Для решения задачи можно создать общий реквизит " ВключатьВРезервнуюКопию " и включить в его состав большинство прикладных объектов. Далее можно реализовать регламентное задание или обработку с пользовательским интерфейсом, которые будут по некоторым правилам проставлять этот признак. Например, признак может быть проставлен документам, введенным за последние 12 месяцев. Соответственно реализуемый механизм выгрузки будет использовать этот реквизит для отбора выгружаемых значений. Разумеется, данную задачу можно решить и другими способами. Здесь она приведена для иллюстрации тех случаев, в которых имеет смысл применять общие реквизиты без разделения данных.

Заметим, что круг таких задач достаточно узок. Важно при принятии решения об использовании общего реквизита оценить правильность применения этого механизма для решения конкретной задачи. Неправильное применение данного механизма может неоправданно усложнить разработку и поддержку конфигурации. В частности, общие реквизиты могут усложнить понимание конфигурации другими разработчиками, так как устройство конкретного прикладного объекта будет менее очевидным и наглядным.

Особенности предопределенных элементов объектов метаданных при работе с отключенным режимом совместимости

Для некоторых объектов метаданных в платформе "1С:Предприятие 8" есть возможность задавать в конфигурации предопределенные элементы, для которых в информационной базе будут автоматически создаваться объекты с заданными значениями. В данной статье рассматриваются некоторые особенности их реализации и работы с ними.

Общие сведения

Объекты данных обладают свойством ИмяПредопределенныхДанных , с помощью которого можно управлять их связью с метаданными. Объекты, у которых данное свойство заполнено, являются предопределенными.

Данное свойство может принимать следующие значения:

Если объекту данных установить пустое значение свойства, то он станет обычным, не предопределенным, объектом.

Если объекту установить имя предопределенного элемента из метаданных, то он станет предопределенным элементом, связанным с метаданными. В пределах одной области информационной базы допустимо использование только одного объекта данных, связанных с конкретным предопределенным элементом метаданных.

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

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

Предопределенные элементы можно редактировать, удалять, помечать на удаление. Имеются специальные права для управления ограничениями на удаление предопределенных.

Рассмотрим следующий пример. В некоторой информационной базе в плане счетов находится элемент данных с кодом А. В какой-то момент решили добавить предопределенный элемент А с кодом А. При реструктуризации в базе данных он будет создан, но существующие ссылки будут ссылаться на существовавший ранее объект данных. Выполнив следующую последовательность команд, можно сделать существующий объект предопределенным:

В результате при обращении к предопределенному элементу А будет возвращен существовавший ранее объект данных А.

Свойство ИмяПредопределенныхДанных доступно в запросах (поле выбора и в условиях), в формах, таблицах и др. Данное свойство обладает особенностями сортировки: сортировка выполняется по внутреннему ключу, а не по строке.

Работа с разделителями

Предопределенные элементы могут использоваться в информационных базах, имеющих общие реквизиты, разделяющие информационную базу в режиме Независимо или Независимо и совместно .

Рассмотрим работы с предопределенными элементами с различными режимами разделения на примере справочника.

Вариант 1. Общий реквизит разделяет информационную базу в режиме Независимо . При получении ссылки на предопределенный элемент выполняется запрос к данным таблицы. Поэтому перед получением ссылки на предопределенный элемент необходимо, чтобы в сеансе было установлено значение и включено использование реквизита, являющегося разделителем. При обращении к данным таблицы предопределенные элементы будут созданы, за исключением случаев:

Предопределенные элементы уже были созданы (проинициализированы) ранее.
Отключено автоматическое обновление предопределенных данных.

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

Вариант 3. Общий реквизит разделяет информационную базу в режиме Независимо и совместно , использование реквизита включено в текущем сеансе работы. При попытке получить ссылку на предопределенный элемент будет возвращена ссылка на предопределенный элемент из текущей области данных. Если запрашиваемая ссылка отсутствует (например, удалена пользователем), то вызывается исключение. При обращении к данным таблицы предопределенные элементы будут созданы, за исключением случаев:

Предопределенные элементы уже были созданы (проинициализированы) ранее.
Отключено автоматическое обновление предопределенных данных.

Внутренний идентификатор

Предопределенные элементы имеют уникальный идентификатор. Уникальность идентификатора проверяется в пределах независимых областей информационной базы данных, по аналогии с другими объектами данных.

Связь предопределенного элемента с метаданными осуществляется через свойство ИмяПредопределенныхДанных .

Обновление конфигурации базы данных

При отключении режима совместимости 8.3.2 или ниже:

Изменяется структура таблиц. Добавляются новые служебные таблицы. Это требует монопольного доступа к информационной базе
Существующие предопределенные элементы модифицируются, внутренние идентификаторы не изменяются. Такие элементы могут безболезненно возвращены к режиму совместимости 8.3.2 или ниже.
Включаются новые возможности по работе с предопределенными элементами.

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

Создаются новые предопределенные элементы, которые были добавлены по отношению к конфигурации базы данных. Например: Если в конфигурации базы данных есть предопределенный элемент с именем А и добавили предопределенный элемент с именем Б в конфигурации будет создан предопределенный элемент с именем Б. Предопределенный элемент с именем А не будет создан, даже если он был удален пользователем из данных. Предопределенные элементы создаются только в тех областях, которые были проинициализированы: либо пользователь уже обращался к предопределенным данным из этой области, либо с помощью специального метода языка ИнициализироватьПредопределенныеДанные().
Удаленные по отношению к конфигурации базы данных предопределенные элементы помечаются на удаление и у них сбрасывается признак предопределенного. Например: в конфигурации базы данных имеются элементы А и Б и в конфигурации удален элемент Б. в данных при реструктуризации объекты данных, связанные с элементом Б (если они есть) будут помечены на удаление и у него будет сброшен признак предопределенного. Свойство ИмяПредопределенныхДанных будет пустым.
Модифицированные в конфигурации предопределенные элементы, модифицируются в данных, если они не редактировались пользователем.

При включении режима совместимости:

Изменяется структура таблиц. Удаляются служебные таблицы. Это требует монопольного доступа к ИБ
Существующие предопределенные элементы проверяются на возможность возврата к режиму совместимости 8.3.2 или ниже. Если возврат невозможен – в конфигураторе выводится соответствующее предупреждение. Несовместимые предопределенные элементы будут помечены на удаление и будет сброшен признак предопределенного элемента. Недостающие предопределенные элементы будут созданы.
Выключаются новые возможности по работе с предопределенными элементами.

Поведение идентификаторов предопределенных элементов при копировании и объединении конфигураций

В отличие от идентификаторов объектов метаданных, идентификаторы предопределенных элементов при копировании не изменяются. Таким образом, два различных объекта метаданных могут иметь предопределенные элементы с одинаковыми идентификаторами.

Теперь рассмотрим, как описанные принципы влияют на поведение предопределенных элементов в различных механизмах платформы "1С:Предприятие 8".

Объединение конфигураций

При объединении конфигураций сопоставление между предопределенными элементами выполняется только по идентификатору, а не по имени или коду. Это следует учитывать при выборе правила объединения свойства Предопределенные данные .

Рассмотрим следующую ситуацию. Вы разрабатываете конфигурацию и устанавливаете ее у заказчика. В процессе настройки возникает необходимость срочной доработки, в частности, добавления предопределенного элемента. Затем в своей основной разрабатываемой конфигурации вы "синхронизируете" изменения, добавляя такой же элемент, осуществляете еще какие-то доработки и приносите новую версию к заказчику.

Если при выполнении объединения конфигураций оставить правило по умолчанию - Взять из конфигурации поставщика , то в результате останется только "ваша" версия элемента. При выполнении обновления конфигурации информационной базы, как было описано выше, будет создан новый объект, а старый помечен на удаление.

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

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

Однако различия в предопределенных данных не всегда приводят к подобным проблемам. Рассмотрим другой возможный сценарий. Вы выгружаете конфигурацию в файл, затем редактируете ее где-то в стороне, например, дома. В процессе редактирования добавляются новые предопределенные элементы и, возможно, удаляются или редактируются существующие. Затем выполняется объединение новой версии с оригинальной конфигурацией. В этом случае можно оставить правило объединения Взять из файла . Как уже отмечалось, в процессе перемещения между различными конфигурациями идентификаторы элементов не изменяются, и все старые элементы вернуться со своими оригинальными идентификаторами.

Режимы обновления предопределенных данных

С целью более удобной организации обмена предопределенными данными реализован механизм управления режимами обновления предопределенных данных. Режим обновления предопределенных задается отдельно для каждого объекта метаданных.

Режим обновления можно задать:

В метаданных, с помощью свойства ОбновлениеПредопределенныхДанных .
В данных, с помощью метода УстановитьОбновлениеПредопределенныхДанных .

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

Сначала значения Авто в метаданных и в данных подменяются ОбновлятьАвтоматически в центральном узле и в НеОбновлятьАвтоматически в периферийных узлах.
Затем по условию <Значение в данных> И <Значение в метаданных> определяется необходимость обновлять предопределенные.

Конфигурация центрального узла:

Значение в метаданных – ОбновлятьАвтоматически .

Значение в данных – Авто .

Значение в данных подменяется на ОбновлятьАвтоматически .

ОбновлятьАвтоматически И ОбновлятьАвтоматически = ОбновлятьАвтоматически .

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

Конфигурация периферийного узла:

Значение в метаданных – Авто .

Значение в данных – ОбновлятьАвтоматически .

Значение в метаданных подменяется на НеОбновлятьАвтоматически .

НеОбновлятьАвтоматически И ОбновлятьАвтоматически = НеОбновлятьАвтоматически.

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

Данные режимы позволяют установить дополнительные правила для удобного обмена предопределенными данными.

Если итоговый режим равен ОбновлятьАвтоматически :

Предопределенные элементы обрабатываются при реструктуризации.
Предопределенные элементы создаются при первом обращении к таблице, если они не создавались до этого.
Предопределенные элементы создаются при вызове метода ИнициализироватьПредопределенныеДанные() , если они не создавались до этого.

Если итоговый режим равен НеОбновлятьАвтоматически :

Предопределенные элементы не обрабатываются при реструктуризации
Предопределенные элементы не создаются при первом обращении к таблице.
Предопределенные элементы не создаются при вызове метода ИнициализироватьПредопределенныеДанные .

Обмен данными

Предопределенные объекты данных передаются по аналогии с другими объектами данных.

Рассмотрим следующий сценарий. В обмене участвуют две информационные базы, имеющие независимые (разные) конфигурации. В этих конфигурациях есть справочники, между которыми установлена связь. В обеих конфигурациях мы добавили предопределенный элемент, имеющий идентичное имя. В конфигурации 1 обновление предопределенных для этих справочников выполняется автоматически, а в конфигурации 2 автоматическое обновление предопределенных не выполняется. При обновлении конфигурации (при первом обращении или при инициализации информационной базы) предопределенные элементы будут созданы в конфигурации 1 и не будут созданы в конфигурации 2. После формирования обменного пакета из конфигурации 1 в конфигурацию 2 предопределенные элементы передаются вместе с другими объектами данных и автоматически связываются по имени предопределенного.

Общие правила обмена объектами метаданных между конфигурациями

В процессе разработки часто возникает необходимость переноса объектов метаданных между конфигурациями. Платформа 1С:Предприятие 8 предоставляет несколько механизмов, которые в той или иной степени позволяют решать данную задачу. К ним относятся:

Копирование объектов метаданных через буфер обмена
Объединение конфигурации с файлом
Загрузка конфигурации из файла
Хранилище конфигурации
Обновление конфигурации, находящейся на поддержке
Обновление конфигурации базы данных

В данной статье рассматриваются некоторые особенности работы этих механизмов, которые позволяют прогнозировать результат перемещений объектов по "цепочкам" конфигураций и правильно выбирать соответствующий механизм. Следует заметить, что статья не является подробным руководством по использованию данных механизмов.

Сопоставление объектов. Имя и идентификатор объекта метаданных

При перемещении объектов между конфигурациями важную роль играет вопрос их сопоставления. Необходимо иметь возможность определить, являются ли два данных объекта разными объектами или копиями одного и того же объекта. Предположим, что мы тем или иным способом скопировали объект из одной конфигурации в другую, а затем выполнили объединение этих конфигураций. Естественно ожидать, что платформа определит соответствие двух объектов, а не будет считать их разными объектами с одинаковыми именами. Для сопоставления объектов используются имя и внутренний идентификатор объекта. И если имя в процессе перемещения объекта, как правило, не изменяется (в любом случае мы можем его контролировать и, при необходимости, модифицировать), то внутренний идентификатор объекта ведет себя по-разному в зависимости от используемого механизма. В приведенной ниже таблице описываются способы сопоставления объектов и поведение внутренних идентификаторов при использовании разных механизмов.

Механизм Способ сопоставления Поведение идентификатора при перемещении объектаКопирование через буфер обмена Сопоставление не используется. Объект всегда вставляется как новый. ИзменяетсяОбъединение конфигураций Сопоставление по имени. При отсутствии соответствия по имени – сопоставление по внутреннему идентификатору. Возможна ручная установка соответствия. При копировании нового объекта изменяется. При объединении двух объектов, между которыми обнаружено соответствие, не изменяется.Сохранение в файл и загрузка конфигурации При загрузке выполняется полная замена на новую конфигурацию. Сопоставление не используется. Не изменяетсяХранилище конфигурации При подключении к хранилищу выполняется загрузка конфигурации. При последующих операциях - сопоставление по идентификаторам. Не изменяетсяОбновление конфигурации базы данных Сопоставление по идентификаторам. В случае нарушения соответствия, данные информационной базы будут потеряны. Не изменяетсяОбновление конфигурации находящейся на поддержке

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

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

Три уровня работы механизмов

Таким образом, механизмы переноса объектов можно разделить по трем уровням:

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

Можно определить следующее правило:

Для обеспечения корректного сопоставления объектов уровень механизмов нельзя понижать.

Например, имеются две конфигурации: одна, в которой ведется разработка и вторая - в "рабочей" базе. Новые версии разрабатываемой конфигурации переносятся при помощи механизма загрузки конфигурации с последующим обновлением конфигурации базы данных. Используемый механизм переноса объектов относится к первому уровню, и идентификаторы при переносе не изменяются. Предположим, что для очередного обновления был использован механизм объединения конфигураций. Проблемы при этом не возникнет, поскольку для "старых" объектов, присутствовавших в предыдущих версиях, идентификаторы не изменились. Однако новые объекты попали в "рабочую" базу с измененными идентификаторами. Для дальнейших переносов новых версий нужно будет использовать только механизм объединения конфигураций, поскольку при выполнении загрузки (то есть при понижении уровня механизма со второго на первый), идентификаторы некоторых объектов "восстановятся" с точки зрения конфигурации разработки, но изменятся с точки зрения "рабочей" конфигурации. В этом случае при обновлении конфигурации базы данных произойдет потеря данных.

Примеры

Параллельное создание объектов

Используется одна конфигурация в двух разных базах: в базе разработки и в базе заказчика. При обновлении конфигурации заказчика, была на месте произведена доработка, в результате которой в базу был добавлен новый объект. Затем в конфигурации разработки этот объект был добавлен вручную. Фактически мы воспользовались механизмом третьего уровня (поскольку идентификаторы у объектов получились разные). Для дальнейшей синхронизации конфигураций без потери данных можно применять только объединение (механизм третьего уровня). Для того, что бы избежать подобных проблем, следует после доработки у заказчика сохранить конфигурацию в файл, а затем загрузить ее в базу разработки.

Восстановление автоматической поддержки конфигурации поставщика

Конфигурация находится на поддержке в полностью автоматическом режиме (с отключенной возможностью изменений). Предположим, что в какой-то момент возможность изменений была включена. Например, это понадобилось для срочного исправления ошибки. После исправления ошибки поставщиком, возникла необходимость отключить возможность изменений для облегчения последующих обновлений. Но это приведет к понижению уровня механизма, а следовательно гарантированного сохранения данных информационной базы при этом добиться будет невозможно. Следует создать новую базу из дистрибутива конфигурации поставщика (с выключенной возможностью изменений) и программно перенести в нее данные.

Примеры анализа цепочки изменений конфигурации

Приведем несколько примеров анализа цепочки изменений конфигурации с точки зрения возможности потери данных.

Например, конфигурация хранилища была сохранена в файл. Это механизм первого уровня. В другой базе было выполнено объединение конфигурации с этим файлом. Уровень повысился до третьего. Затем возникла необходимость подключить эту базу к хранилищу. Механизм хранилища работает на первом уровне, поэтому при этом будет возможна потеря данных.

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

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