Генератор SQL скрипта для переноса данных

0. 194 16.01.22 11:50 Сейчас в теме
Обработка, генерирующая SQL скрипт для переноса данных между базами 1С с одинаковыми конфигурациями, но с разными именами таблиц и полей SQL.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. SerVer1C 497 17.01.22 10:45 Сейчас в теме
"...у базы1 и у базы2 конфигурации одинаковы..." ~~~ "...для составных типов поля "_Fld...TYPE" отличаются..."
что-то тут не чисто
2. info1i 194 17.01.22 11:05 Сейчас в теме
(1) Попробуйте создать новую пустую базу и загрузите в нее конфигурацию из другой базы, после зайдите на СУБД и проверьте имена таблиц, полей, типы составных реквизитов - станет понятно.
3. SerVer1C 497 17.01.22 11:41 Сейчас в теме
(2) у меня совпало, ЧЯДНТ ?
поле _Fld{X}_TYPE всегда binary(1)
поле _Fld{X}_RTRef всегда binary(4)
поле _Fld{X}_RRRef всегда binary(16)
4. werd00 17.01.22 12:16 Сейчас в теме
(3) Базы с разной структурой имеют разные названия полей. Автор по имени объекта метаданных пытается их сопоставить. когда на один реквизит попадает насколько имен полей( в случае составного типа) не совсем понятно как их сопоставлять для скрипта переноса. (я руками прописывал такие исключения). Например для реквизита1 есть поля _Fld2_TYPE,_Fld2_S и т д. а в базе 2 они имеют названия _Fld5_TYPE, _Fld5_S. и точного соответствия, что _Fld2_TYPE должен переходить в _Fld5_TYPE - нет.

а про поля автор писал, "составных типов", а не типы колонок sql
5. SerVer1C 497 17.01.22 12:31 Сейчас в теме
(4) Так вы же понимаете, что несоставное поле А переходит в несоставное поле Б. И тут аналогично. У составного поля в эске есть 3 поля в скуле. Номера в имени скульного поля у них одинаковы, например, _Fld12345_TYPE, _Fld12345_RTRef, _Fld12345_RRRef
6. werd00 17.01.22 12:41 Сейчас в теме
(5) не совсем так. условно есть реквизит1 у справочника1. реквизит простой. поэтому можно сопоставить на 100%
что поле _Fld1 - ,будет у одноименного реквизита в базе 2 - _Fld5 ( к примеру). это можно получить сравнивая таблицу хранения данных. В случае составного типа, у вас для реквизита 1 будет несколько полей. и надо поле *_TYPE" одной базы, сопоставить с полем "*_TYPE" другой базы. При этом имя поля у них одинаковое.
Прикрепленные файлы:
7. werd00 17.01.22 12:49 Сейчас в теме
(5) а вторая проблема в типами. это то что документ1 имеет тип 0x000002B3 (к примеру) , в вот одноименный документ в другой базе имеет тип 0x000002С5. и при переносе надо учитывать это, и вставлять не 0x000002B3 , а 0x000002С5
SerVer1C; info1i; +2 Ответить
8. info1i 194 17.01.22 13:15 Сейчас в теме
(7) Да, верно, именно в данном случае стопор.
9. werd00 17.01.22 13:56 Сейчас в теме
(8) ну здесь могу только предложить выгружать типы вместе со структурой, а при генерации скрипта сделать конструкцию вида case when .. then../ но это , наверное, несколько громоздко будет. подмены на каждый вид справочника и документа.
10. SerVer1C 497 17.01.22 15:27 Сейчас в теме
(8) Не вижу в этом проблем. Мы однозначно можем определить, что тип, например, 0xDEADBEEF - это Док.А, и в другой базе подставим свой 0xCAFEBABE
11. werd00 18.01.22 06:27 Сейчас в теме
(10) Ну никто и не говорил, что это нерешаемая проблема:)
12. NeLenin 8 18.01.22 08:19 Сейчас в теме
Можно и так. Но я бы решил такую задачу через CREATE VIEW для каждой БД
13. user1203706 18.01.22 20:07 Сейчас в теме
(0) Для большой базы, в разы быстрее делать перенос не через select into, а через выгрузку в файлы в скуле и дальше загрузку из файлов. Там используется булк инсерт.
А то что у вас...можно ожидать неделями, для большой базы
14. info1i 194 18.01.22 20:41 Сейчас в теме
(13) Это да, согласен. Однако Bulk insert имеет свои ограничения и минусы.
16. werd00 19.01.22 07:59 Сейчас в теме
(13) А для вас "большая база" это сколько? Если не секрет.
Из личного опыты: подобный механизм работал меньше часа, База 35 гб, примерно 1300 таблиц.И это не самый шустрый сервер - проц I5-8500 , 32гб ОЗУ.
15. user1203706 18.01.22 21:29 Сейчас в теме
(14) Для данной задачи, ограничений нема.
17. user1203706 19.01.22 09:32 Сейчас в теме
(16) Перенос одного РС, 250 млн записей, способом из 0 занял сутки. Через булку, менее полчаса.

(1) Хотя бы воткни truncate table , заместо delete
+воткни фильтры на объекты метаданных при выгрузке.

Как потом в простынке получившегося скрипта из тыщи таблиц удалять/искать нужные, если нужны не все ?

+Твой код, учитывает расширения ? Когда данные будут в табличка с суффиксом X ?

+не ясна цель такого переноса, в пустую базу (ты же всё равно данные в ней прибиваешь, судя по delete) ?

когда проще поднять архив источника.
SerVer1C; +1 Ответить
Оставьте свое сообщение
Вакансии
Аналитик БИТ.Строительство
Москва
зарплата от 150 000 руб. до 250 000 руб.
Временный (на проект)

Программист 1С
Новосибирск
зарплата до 230 000 руб.
Полный день

Программист, аналитик, эксперт 1С
Санкт-Петербург
По совместительству

Архитектор 1С
Москва
зарплата от 260 000 руб.
Полный день

Начальник отдела архитектуры
Москва
зарплата от 300 000 руб.
Полный день