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
Sven
Subscribe to:
Post Comments (Atom)
3 comments:
Sadly, all this renaming of objects is nothing new. They did the same moving from 2.5 to 3.0 and despite reasoned arguments against (it creates a huge amount of work for partners for little or no benefit) continue to do so without any thought for the pain they cause us. I mean, renaming CountryId to CountryRegionId; what was the point of that! Its almost as though they do it on purpose to annoy us. :-)
Hi,
Indeed yes they did however this time around I get the impression they were even more vicious and really created work for all the consultants working on their products.
Useless time wasting work.
/Sven
These do add a pain factor, but do make sense to those new to Ax.
The main problem we fight with is the data upgrade where the sql dictionary does not match the database or AOT; so a string field in the AOT can map to a numeric field in the database (which is how we found it) - it's even more dangerous when the change seems valid to SQL and allows it to continue putting the wrong data in the wrong column!
Just found an AOT error in a class where a method just appeared to move from one class to another causing a compilation error: the method is in the SYS layer, so a developer couldn't have done this, right?
Post a Comment