Переход с Axapta 3.0 на AX 2009 - критика утилиты конвертации БД и скриптов обновления

[someOne]

Совершенно согласен с вами, gl00mie.
Видимо, при создании этой процедуры руководствовались лишь чисто теоретической возможностью перехода, не думая о том с какими сложностями придется столкнуться разработчикам Аксапта при переходе.

Для себя решил проблему написанием собственного скрипта (на C#) по переносу данных из Ax 3.0 (Oracle) --> Ax2009 (MSSQL)

Удалось решить сразу ряд проблем
- Не нужна подготовка исходной базы данных
- Весь перенос данных происходит в один заход, при этом происходят все необходимые этапы (Преобразование Unicode, Выравнивание влево, конвертация DateTime, конвертация типов int--> int64, конвертация спец символов Orale пустой строки в "")
- Переносятся только те данные которые используются в новой версии.
Например ряд таблиц, типа DataBaseLog, Xref*, SalesParm* и так далее при переносе пропускаются, что так же экономит время.

Скрипт лишь наполняет "пустую", подготовленную заранее базу данных Ax2009 данными, в уже существующие таблицы Ax2009 из базы Ax 3.0 средствами SQL (Bulk Copy).

При этом происходит сравнивание таблиц SQLDictionary исходной и итоговой базы,
и переносятся данные в соответствии с кодами таблиц и полей, даже если они были переименованы в новой версии Аксапта.

После работы скрипта остается лишь реиндексировать базу (скрипт удаляет индексы для ускорения переноса данных), так как база до этого уже полностью была синхронизована.

Скрипт позволяет перенести базу 150 GB за
- 9 часов при одно поточном запуске
- 4 часа (ели запустить скрипт в 3-х потока одновременно на разных серверах.)

+ 4 часа на полную индексацию...

Не понятно почему в MS не могли написать "нормальную", удобную процедуру конвертации, с их возможностями разработки ?

Кстати, по поводу ENUM- ов. Вы имеете ввиду процедуру "последующей синхронизации" ?.
Что то про ENUM - ы я ничего не встречал в описании процедуры конвертации...