Условия задачи:
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 и выполнить последние шаги этой утилиты.
Ваше мнение, идеи ?