C# and AX Development: Experiences upgrading Axapta 3.0 to Dynamics AX 4.0

[Blog bot]

Источник: http://olondono.blogspot.com/2008/08...pta-30-to.html
==============

Some notes from my experience upgrading Axapta 3.0 to Dynamics AX 4.0 in Transportes Botero Soto, Colombia.

- Any modification in system classes must be removed before make the upgrade. After that, you can apply changes manually. (ex. Avoiding users to open more than one session in Axapta (Dynamics AX))

- In Axapta 3.0, we had created a CustomerRef field in the SalesLine table. In AX, this field was created by Microsoft. So, to avoid conflict, we need delete it before perform the AOT conversion.

- For releasing disk space, we can delete data in tables like sysDatabaseLog, sysUserLog, axOldRecIds, axOldToNewRecIds, OlapAmount. Also, we can truncate the transaction log before conversion. See How to truncate any Database's log file.

- The class ledgerJournal not exist anymore in AX 4.0 and if you are using it for generate a ledger journal number, you must change the code ledgerJournal.newJournalNum(true); by NumberSeq::newGetNum(LedgerParameters::numRefJournalNum(), true).num();

- The class Specification was changed in 4.0. Now, we must set the reference table id parameter.

- Instancing before: specification = new Specification_OffsetVoucher(vendTable.tableId, vendTable.recId); now, specification = Specification::construct(SpecType::OffsetVoucher, vendTable.tableId, vendTable.recId);

- For the specification creation now we must include the table's id: specification.create(vendSettlement.TableId, vendSettlement.recId, vendSettlement.settleAmountCur, _vendTrans.currencyCode);

- For delete one specification (marked open transactions), before: specification.deleteTransact() and now specification.deleteSpecifications()

- The field specTrans.RefId not exist anymore, now it is called RefRecId and also, we must set the field RefTableId.- RecIds in AX 4.0 are long-integers (64-bits), for that reason, any assignment with an integer variable will lost precision/accuracy, so we must ensure that any custom field related to RecIds, is large as 64-bits.

- If we have modified Forms in Axapta 3.0, we must make the conversion manually, we can use this technique for optimize the copy of tabs, controls, buttons, methods, etc. Duplicate the converted form, delete it from the custom layer (in our case: CUS), then use drag and drop for any custom control and owner method.

- Good coding practices make easiest the conversion:

- Put comments at the starting and ending block of source code modified (//Ini TBS … // End TBS…) and always try to write a good explaination for reasons you had made the change (that is not obvious for anyone different than you).

- Use braces "{}" to identify correctly blocks of source code, no matter if the instruction only takes one line. This provide a good "eagle view" for any change and inherent logic, avoiding waste of time.

- Use spaces with assignment or logic operators ("x = y" instead of "x=y"). Again, this provide an "eagle view" because the brain doesn't need to separate every instruction's member.

- Use four (4) spaces indentation (recommended).

- Use parenthesis "()" when logic instructions comes, ex. if (x==y && z!=w || x!=w is less visible than if ( (x == y) && (z != w) || (x != w)) … in the last one, you can identify operators quickly.

- Use two or more lines for "select" instructions putting the "index", the "where" and logic instructions in their own indented line. This show the real objective of the "select" instruction.

- When we need to hide/remove an user control, the best choice is doing it by code (element.control.visible(false);).

- If you need to change standard code, you must enclosed it with comments and work with a copy to avoid lost of tracing.

- Any custom menu must be added manually, to avoid lost of properties like icon, help text, ext.

- EDTs in version 4.0 should be left aligned instead of right aligned like in version 3.0. You must review custom tables to get a better performance from SQL Server.

- Reference to non-existing labels can be found looking from the root node every item that contents data like "@GLxxxx".

- If you need to change a base enum, the new items can produce conflicts with new standard items in future versions. To avoid this, you can set the value for new custom items starting from a none typical value like 50, 51, 52, etc.

- In the conversion, post-syncrhonization, if you get an error from SalesTable and SalesLine (fields ShippingDateRequested and ShippingDateConfirmed), is probable that you have records in SalesTable without lines in SalesLines. Then, you need to remove that records.

- The upgrade process for the database could raise an error with the table AxOldToNewRecIds. In several groups, I found that this table can be deleted without problem. After upgrade, you can copy the table manually.

- If you have SQL Server 2005 for Axapta 3.0, it is probable that you get some errors with SysDiagrams and dt.Properties. You can delete those objects before use the tool AxDBUpgrade.

- You got the error: Insufficient rights to execute Method … : you must delete all data from SysConfig table (license data table). It will be filled with the correct licenses code when needed.

- Invalid license code for this language. If you have a license for a language different than english, you need to change the value "en-us" by the correct value (ex. "es") for the Administrator user. (Tables dbo.USERINFO and dbo.SYSUSERINFO)

- Error synchronizing the table SalesParmTable because it has duplicated keys. This is an "intermediated" table, so, you can delete its contents(?).

- Synchronization error: "The total, internal size of the records in your joined SELECT statement is 26208 bytes, but Microsoft Dynamics is by default performance-tuned not to exceed 24576 bytes." You need to specify a bigger value in the tab 'SQL in the Dynamics AX Server Configuration tool (Administrative tools). My upgrade value was 49152.

- If you have custom fields in tables smmQuotationLine and smmQuotationTable, you need to change the code in the class ReleaseUpdateDB39_Smm to include all custom fields when upgrading data.



Источник: http://olondono.blogspot.com/2008/08...pta-30-to.html

[sukhanchik]

Информации много и она свалена в кучу - фиг разберешь, если с этим не сталвивался. Начинается сообщение с БД, переключается в приложение (в код) и заканчивается опять БД. Интересно посмотреть на людей, кто одновременно конвертирует формы и производит синхронизацию (особенно на реальных данных). Было бы логичнее написать:
1. Готовим приложение. Обращаем внимание на те элементы, которые изменились и преобразовываем код "к четверке". Попутно конечно можно вообще пересмотреть весь свой функционал - но это уже кому как нравится. Приложение можно готовить на пустой БД.
Думаю, что этот пункт займет от двух недель до.... края бюджета, выделенного на переход на новую версию
2. Готовим БД (пробуем обновить данные на копии рабочей БД) для тестирования приложения. Изучаем все грабли подложенные Микрософтом, попутно разбирая сделанные свои грабли. На диске к 4-ке кстати - это есть как проект с выравниванием типов данных (в котором надо не забыть исключить типы из СНГовых модулей) и пресловутый AxDbUpgrade.exe.
3. Известные свои грабли (обновление данных) добавляем либо в список обновления до синхронизации (классы ReleaseUpdateDB39_*), либо после синхронизации (классы ReleaseUpdateDB401_*). Убеждаемся в отсутствии var/bus слоев.
4. Запускаем процесс перелива данных по изученному в п.2 алгоритму. Попутно ставим 4-ку (АОСы, клиенты и т.д.)
5. Натравливаем подготовленное в п.1 и п.3 приложение на получившуюся БД. Если есть проблемы с запуском - можно вообще приложение без модификаций натравить - лишь бы сформировался пользователь и появилась возможность загрузить лицензии.
6. Смотрим контрольный список обновления. На глоб компиляцию забиваем, если мы ее уже сделали в п.3. Загружаем лицензии и возвращаемся с чистого приложения на свое (если такая подмена делалась). Рестартуем АОС, чтобы он "скушал" лицензии.
7. Не вижу смысла запоминать что где какие поля переименовались. Всего не упомнишь. Есть процедура обновления данных до и после синхронизации. Если после ее выполнения остались грабли - их (грабли) нужно собирать и фиксировать в ReleaseUpdate-классах. Базу-то затем и готовим - чтобы можно было тестировать.
8. После отработки контрольного списка - 4-ка готова. Можно тестить. Все это тестится, исправления вносятся в приложение (в т.ч. в классы ReleaseUpdate*).
9. После массового сбора ошибок - запускается снова процедура переливки БД чтобы "засечь" время и оценить реальное время, которое будет потрачено.
10. Ну и наконец - в час Х все запускается на рабочей БД.

[sukhanchik]

Кстати - пройдя все по шагам - натыкаешься на 2 любопытных следствия из продедуры обновления:
1. Очистка таблицы SysConfig с последующим рестартом АОСа дает возможность зайти в Аксапту (если такой пользователь уже был прописан) и загрузить новые лицензии.
2. Очистка таблицы UserInfo с последующим рестартом АОСа дает возможность зайти в Аксапту под пользователем Admin с админскими правами.

Применение этих двух пунктов последовательно - дает возможность зайти в копию любой БД под любыми лицензиями и правами администратора.

[Vadik]

Цитата:

Сообщение от sukhanchik

1. Очистка таблицы SysConfig с последующим рестартом АОСа дает возможность зайти в Аксапту (если такой пользователь уже был прописан) и загрузить новые лицензии.
2. Очистка таблицы UserInfo с последующим рестартом АОСа дает возможность зайти в Аксапту под пользователем Admin с админскими правами.
Применение этих двух пунктов последовательно - дает возможность зайти в копию любой БД под любыми лицензиями и правами администратора.

Что же тут удивительного - с такими-то правами (очистка системных таблиц + рестарт сервиса)