Wednesday, 14 March 2007

Upgrading from V3 to V4 P3

Well here we go I carry on my run through of some of the obstacles I have faced in upgrading from V3 to V4.

The CreateLine function on the SalesLine Table has an added parameter that controls credit checking behaviour, incosiderately MS have choosen to add the new parameter before the last parameter which is a string. This means that even though it is defaulted if you are using that last parameter your code fails because of type checking.

They should really think before acting !

Hopefully for the future they will not in version 4.1 4.5 5.0 repeat some of these rather cavalier changes all over the place.

What's with the changing of all the tab page elements in all forms to be named Tab, do they not realise what pain they cause for any changed forms, you cannot just migrate you practically have to hand code / port the changes.

And making what I would call gratuitous changes to the names of Tabs inside a form is just silly, why do you need to rename a Tab from NotificationToCentralBank to NotificationToTheCentralBank example taken from the CustTable form.
Anyhow making long names in Ax is sometimes counterproductive as only a certain number of characters are used to distinguish elements so it can actually be dangerous unless V4 is improved in this area.

But in any case such changes are silly and add nothing to the value of the product.

To be continued


Tuesday, 13 March 2007

Upgrading from V3 to V4 P2

As stated in the earlier posting here is the continuation of my meanderings through the process of upgrading Dynamics Ax V3 code to V4.

Several tables have been renamed completely unexpectedly.

I have not found them all mind you just the ones that were used by the code I had the pleasure to upgrade.

The SmmQuotation tables have been renamed SalesQuotationTable which is what everyone knows from the whats new.

What I had no inkling of is that SalesPickingListJournalTable had been renamed to InventPickingListJournalTable likewise the lines and the form that is attached to the lines etc etc. As I had code that was dependent upon this and the code was not being imported it did not switch over to the new naming convention so I had a field day finding everything ;-).

A lot of screens will keel over as MS has had a field day renaming functions all over the place, albeit to more logical names but they should know that doing this is not with out consequences
F'ex the Function EmptyAddressField in the AdressMap which clears the data in the adress fields of any entity with adress fields attached is now called clearAddressField, which is more logical than the old naming convention but it does force you to revisit any code you built around this.

The TmpSalesLine table used by the old Address screen has been renamed to the SalesCreateReleaseOrderLineTmp table however the TmpPurchLine retains its old name, go figure on that one ?

I will continue as I go adding more

Best Regards

Sunday, 11 March 2007

Upgrading from V3 to V4 P1

I have recently been involved in some upgrade projects from V3 to V4 and frankly I am a bit put off by the degree of cavalier change that has been done in the App in V4.

As an example I intend to go through some of the changes and evaluate them as being either positive or negative and also to discuss a little how you can get around them.

As discussed earlier in V4 MS has reduced the usage of layers, put in another fashion they have actually cleaned out the GLS, LOS and DIS layers and put all the code contained here into SYS.

That in itself is not really too much of an issue however they have also in their infinite wisdom decided that they will at the same time renumber the objects that have been moved to give them a SYS id number.

If you do not know what the numbers are or how they relate to layers please read either or other related resources to get more information.

Obviously the fact of renumbering creates all the issues that I pointed to in that previous short article, if you have code that you bring accross in layers (that is pre compiled) you may very easily be subjected to crashes and compile errors that are strange, such as duplicate fields with different ID's.

I have so far been able by deleting each of these fields (and re-booting as the AOS server crashes when you do so) individually to clean up the code as regards these fields, however there are a number of EDT's that had previously been named slightly erroneously or that could cause confusion that have been renamed.

An example is the Country EDT which is now called CountryRegionId, there are quite a number of these renames and if you combine the field duplication with a rename you wind up having a table with the country code and the countryregionid code perfectly legal with each their ID's but very confused data.

Anyhow I intend to do a series of articles about each of the issues I find and to propose a possible solution for each.

So for the fields you need to compile globally the database and then prepare to restart the AOS the number of times you have the issue of duplicate fields as the deletion of the field will cause an error message :-).

For the Country -> CountryRegionId you need to go through all of the (typically DB trigger code) code where this is used and change the field being referenced to the new field. As for any fields that you may have created in your own extensions of the system up to you: If you rename you are being consistent with the new naming scheme of MS however you will have to add a data manipulation step to the upgrade programs in order to move the data from the old column to the new one.

If you do not change the name then you do not have to move the data however you are not compliant with the new MS ax definitions.

To be continued in a very long series :-(