[SQL, 1С-Битрикс] Переброска данных между идентичными объектами метаданных базы 1С через подмену УИДов в базе SQL
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
При возникновении необходимости миграции с одной конфигурации поставщика на другую, либо при обновлении доработанной конфигурации, если Поставщик позднее добавил тот объект, что был у нас добавлен самостоятельно, может оказаться, что старый и новый объекты имеют разные внутренние идентификаторы. При сравнении/объединении конфигураций видно, что старый документ не находит соответствие с новым, так как у них различные внутренние идентификаторы метаданных, а при загрузке (обновлении) новой конфигурации поставщика старый документ удаляется вместе со всеми введенными документами.
Существует несколько вариантов решения данной проблемы:
А. Перенос удалившихся документов после обновления конфигурации в новый объект метаданных с помощью правил обмена (данный способ рекомендует использовать 1С);
Б. Использование правил настройки сравнения/объединения конфигураций. При этом можно настроить соответствие между старым и новым объектом метаданных. В пользовательской базе останется старый объект (со старым УИДом), а при сравнении/объединении он будет модифицироваться изменениями нового объекта поставщика. Но при этом объект останется со старым УИДом и на поддержку не встанет.
В. Начать использовать новый объект конфигурации поставщика, перекинув в него все данные из старого объекта путем замены УИДов. При этом конфигурацию можно поставить на поддержку, использовать автоматическое обновление, кроме того, не требуется осуществлять как таковой перенос данных. Исключается риск получить неполный перенос данных, битые ссылки и т.д. При данной методике данные вообще не изменяются.
Разберем подробно вариант "В".
- Для того, чтобы стало возможно перекидывание УИДов, необходимо сделать одинаковыми количество и типы реквизитов старого и нового объектов метаданных. Важно, чтобы любому из реквизитов (табличных частей и т.д.) старого документа соответствовал реквизит нового документа с точно таким же типом данных. При этом названия реквизитов значения не имеют. Для проверки был создан тестовый документ с несколькими реквизитами разных типов, в том числе ссылочных, и с табличной частью в первой, «старой» конфигурации. Было создано несколько объектов этого документа с заполненными данными. Во второй, «новой» конфигурации был создан другой документ (не скопирован, а именно заново создан), количество и типы реквизитов — одинаковые:
- Далее базу со старыми документами требуется сравнить/объединить с новой конфигурацией, добавить новый документ, не удаляя при этом старый. Запускаем обновление конфигурации базы данных, чтобы изменения полностью применились и не было отличий основной конфигурации и конфигурации базы данных. В итоге после объединения в базе должны появиться два вида документов: старый, с заполненными данными, и новый — пустой. При этом, повторюсь, реквизиты документов должны полностью совпадать по типам данных.
- Теперь выгрузим конфигурацию в XML-файлы, чтобы удобно было находить все интересующие нас УИДы:
- Открываем файл «старого» документа (ivi_ТестовыйДокументУКФ.xml), ищем и фиксируем УИДы его самого и всех его реквизитов и табличных частей:
УИД документа:
УИД реквизита:
Табличная часть также имеет свой УИД:
- Далее делаем тоже самое для «нового” документа.
- В итоге получается два списка, для старого и нового объектов:
- Теперь, зная УИДы,, отправляемся в базу данных для их замены.
https://its.1c.ru/db/metod8dev/content/1798/hdoc — статья на ИТС с подробным описанием структуры хранения данных в БД.
Нас интересует таблица Params, в которой расположены соответствия между объектами конфигурации 1С и таблицами базы MS SQL. Данные соответствий хранятся в текстовом формате, упакованном алгоритмом Deflate:
- Выгружаем из таблицы Params двоичные данные файла с именем DBNames:
Через SQL Management studio данные выгружаются в формате HEX, где каждый символ кодируется двумя шестнадцатеричными знаками, так как выгружается в текстовом виде. Для дальнейшей работы с данными их необходимо преобразовать из формата HEX в формат BIN. Подойдет любой конвертер HEX to BIN. Я использовал конвертер https://tomeko.net/online_tools/hex_to_file.php?lang=en
В итоге получили двоичный файл, по длине совпадающий с длиной поля в БД, 955126 байт.
- Раскодируем полученный файл. Для раскодировки использовал обработку: https://infostart.ru/public/618906/
Распакованный DBNames выглядит следующим образом (слева — УИД 1С, далее — префикс и номер таблицы SQL):
- Наша задача – заменить УИДы 1С между старым и новым документами, не затрагивая при этом имена таблиц SQL.
На рисунке выше УИДы уже заменены.
- Сохраняем файл и упаковываем (Inflate) его с помощью той же обработки, что использовали для распаковки (9)
- С помощью SQL-запроса помещаем новый файл в DBNames:
UPDATE [ukf_real_test].[dbo].[Params] SET [BinaryData] = (
SELECT *
FROM OPENROWSET(BULK N'C:\DBNames-FM.dfl', SINGLE_BLOB) tt) where [FileName] = 'DBNames'.
Следующим запросом устанавливаем поле с длиной двоичных данных в правильное значение, чтобы не возникло внутренней ошибки в 1С при обращении к ним:
UPDATE [ukf_real_test].[dbo].[Params] SET [DataSize] = 954234 where [FileName] = 'DBNames';
- Откроем конфигуратор 1С. Необходимо, чтобы 1С реструктуризировал данные измененного документа. Для этого необходимо внести любое изменение в состав или значения реквизитов и сохранить, обновив конфигурацию базы данных.
- После реструктуризации запускаем 1С в режиме предприятия.
Все данные из „старого“ документа перешли в „новый“:
Состояние документов и ссылки рабочие.
База 1С обновляется, реструктуризируется без ошибок.
При загрузке новой конфигурации старый документ, в котором уже нет объектов, удаляется, а все документы остаются в новом.
Данная статья описывает лишь принцип работы с данными. Осуществлять вручную подмену УИДов, в особенности для объектов с большим числом реквизитов, — достаточно трудоемко и имеет смысл автоматизировать данный процесс.
===========
Источник:
habr.com
===========
Похожие новости:
- [Управление персоналом, Карьера в IT-индустрии] Брайан Фитцпатрик, Бен Коллинз-Сассмэн «Team Geek: идеальная IT-компания»: смысл и законы командной работы
- [MySQL, Администрирование баз данных] Репликация баз данных MySQL. Введение
- [PostgreSQL, .NET, API, C#] Development of “YaRyadom” (“I’mNear”) application under the control of Vk Mini Apps. Part 1 .Net Core (перевод)
- [Программирование, Go] Методы организации DI и жизненного цикла приложения в GO
- [PostgreSQL, SQL, Администрирование баз данных, Визуализация данных] One Tool to Analyze Them All
- [Python, SQL] Немного SQL алхимии
- [MySQL, SQL, Администрирование баз данных, Управление разработкой] Серия мастер-классов по MySQL 15—17 декабря
- Выпуск СУБД SQLite 3.34.0
- [Системное администрирование, PostgreSQL, Серверное администрирование, Администрирование баз данных] Настройка пользователей только для чтения в PostgreSQL (перевод)
- [Разработка под iOS, Разработка мобильных приложений, Swift] Как мы стартовали Vivid Money для iOS
Теги для поиска: #_sql, #_1sbitriks (1С-Битрикс), #_ivi, #_1s (1С), #_sql, #_dbnames, #_blog_kompanii_onlajnkinoteatr_ivi (
Блог компании Онлайн-кинотеатр ivi
), #_sql, #_1sbitriks (
1С-Битрикс
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 06:52
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
При возникновении необходимости миграции с одной конфигурации поставщика на другую, либо при обновлении доработанной конфигурации, если Поставщик позднее добавил тот объект, что был у нас добавлен самостоятельно, может оказаться, что старый и новый объекты имеют разные внутренние идентификаторы. При сравнении/объединении конфигураций видно, что старый документ не находит соответствие с новым, так как у них различные внутренние идентификаторы метаданных, а при загрузке (обновлении) новой конфигурации поставщика старый документ удаляется вместе со всеми введенными документами.   Существует несколько вариантов решения данной проблемы: А. Перенос удалившихся документов после обновления конфигурации в новый объект метаданных с помощью правил обмена (данный способ рекомендует использовать 1С); Б. Использование правил настройки сравнения/объединения конфигураций. При этом можно настроить соответствие между старым и новым объектом метаданных. В пользовательской базе останется старый объект (со старым УИДом), а при сравнении/объединении он будет модифицироваться изменениями нового объекта поставщика. Но при этом объект останется со старым УИДом и на поддержку не встанет. В. Начать использовать новый объект конфигурации поставщика, перекинув в него все данные из старого объекта путем замены УИДов. При этом конфигурацию можно поставить на поддержку, использовать автоматическое обновление, кроме того, не требуется осуществлять как таковой перенос данных. Исключается риск получить неполный перенос данных, битые ссылки и т.д. При данной методике данные вообще не изменяются. Разберем подробно вариант "В".
Данная статья описывает лишь принцип работы с данными. Осуществлять вручную подмену УИДов, в особенности для объектов с большим числом реквизитов, — достаточно трудоемко и имеет смысл автоматизировать данный процесс. =========== Источник: habr.com =========== Похожие новости:
Блог компании Онлайн-кинотеатр ivi ), #_sql, #_1sbitriks ( 1С-Битрикс ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 06:52
Часовой пояс: UTC + 5