Ошибки выполнения AxDbUpgrade.exe при копировании данных между базами (AX 3.0 -> AX 4.0)

[dacom]

Условия задачи:

AX 30 SP6 (MS SQL 2005) -> AX 40 SP 1 (MS SQL 2005).

Базы на разных серверах.

Столкнулся с проблемой во время использования утилиты AxDbUpgrade:

1) на ряде таблиц утилита крешилась с вызовом Visual Studio дебагера

2) на некоторых таблицах выполнение останавливалось, но после повторного запуска (либо нескольких запусков, в случае CustInvoiceJour их было 8) AxDbUpgrade таки копировала данные этой же таблицы

Запускал с разным количеством потоков: 1, 2, 4, 8. Результат одинаковый.

Пример лога в случае креша:

ASSETSORTING create OK
ASSETSORTING bcp OK
, overwriting import format OKASSETSORTING bulk insert OK, Fri Apr 11 16:17:43 2008

ASSETSTATEMENTINTERVAL create OK
ASSETSTATEMENTINTERVAL bcp OK
, overwriting import format OKASSETSTATEMENTINTERVAL bulk insert OK, Fri Apr 11 16:17:43 2008

ASSETSTATEMENTROW create OK
ASSETSTATEMENTROW bcp OK
, overwriting import format OKASSETSTATEMENTROW bulk insert OK, Fri Apr 11 16:17:44 2008

ASSETTABLE create OK
ASSETTABLE bcp OK

Проблему №1 решал подменой файла *.fmt, созданного AxDbUpgrade перед крешем, на файл, который получал при помощи bcp утилиты.

Для некоторых таблиц файл *.fmt был пуст, для других заполнен, но поле RecVersion пропускалось (привожу пример строки fmt файла):
52 SQLINT 1 4 "" 52 skipped ""

Есть подозрение на порядок полей в SQL таблицах.
После миграции с Oracle во многих таблицах поле RecVersion стало первым по порядку.

В базе 4.0 поле RecVersion определенно как not null, в базе 3.0 часто значение именно null.
Установка RecVersion в "1" в базе 3.0 (например InventTrans) не решило проблему.

Проблему #2 решал многократным перезапуском AxDbUpgrade.
2 таблицы CustInvoiceTrans и InventTrans в конце концов перегнал средствами SQL importа и добавил записи в UNICODECONV, дабы обмануть AxDbUpgrade и выполнить последние шаги этой утилиты.

Ваше мнение, идеи ?