Parabellum1905y,

А что там с уникальными индексами?

Посмотреть, что именно Rejected:


Почему:



Ну и да, message файл смотреть.

Ggg_old,

Действительно, что за идиоты?! ;)

Ну подумаешь, там могут быть какие-то вопросы с big endian/little endian, constraint'ы какие-то в базе попадают неизвестным для нас образом (referencial/check/unique), изменение не отразится в последовательности журналов (по которым мы потом будем после восстановления накатываться), и вообще, БД не будет знать о том, что у нас что-то нелогируемым образом поменялось, таблица может жить не в SMS'е (где таблицы по файлам), а в DMS'е, или иметь разную конфигурацию контейнеров в источнике и target'е (да и вообще, таблицы могут иметь разную структуру, не говоря о том, что источник может быть просто сколь угодно сложным запросом), может мы захотим распараллелить загрузку на 20 потоков, переконвертировать character данные между кодировками и т.п.

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

Parabellum1905yпроблема была в полях с GENERATED AS IDENTITY. пришлось в итоге регуляркой удалить из скрипта все подобные строки. и потом добавлять уже отдельно и PK и FK.

Удобно выставить у target таблицы поля IDENTITY как GENERATED BY DEFAULT, а не ALWAYS:
и не сталкиваться с этой проблемой.

Или пользоваться опциями "modified by identityoverride" или "modified by identityignore":

В доке всё более чем прозрачно описано.

PS Не забыть: