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

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. SerVer1C 484 17.01.22 10:45 Сейчас в теме
"...у базы1 и у базы2 конфигурации одинаковы..." ~~~ "...для составных типов поля "_Fld...TYPE" отличаются..."
что-то тут не чисто
2. info1i 192 17.01.22 11:05 Сейчас в теме
(1) Попробуйте создать новую пустую базу и загрузите в нее конфигурацию из другой базы, после зайдите на СУБД и проверьте имена таблиц, полей, типы составных реквизитов - станет понятно.
3. SerVer1C 484 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 484 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 192 17.01.22 13:15 Сейчас в теме
(7) Да, верно, именно в данном случае стопор.
9. werd00 17.01.22 13:56 Сейчас в теме
(8) ну здесь могу только предложить выгружать типы вместе со структурой, а при генерации скрипта сделать конструкцию вида case when .. then../ но это , наверное, несколько громоздко будет. подмены на каждый вид справочника и документа.
10. SerVer1C 484 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 192 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 Ответить
Оставьте свое сообщение
Вакансии
Администратор 1С
Владивосток
зарплата от 150 000 руб.
По совместительству

Руководитель проектов внедрения 1С:УХ
Краснодар
зарплата от 150 000 руб.
Полный день

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

Консультант-аналитик 1С
Москва
зарплата от 120 000 руб. до 190 000 руб.
Полный день

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