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

Платформа 1С v8.3 Конфигурации 1cv8

0. info1i 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

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) ?

когда проще поднять архив источника.

Оставьте свое сообщение

E-mail: