Time to do some philosophing… .
A few years ago, I got the opportunity to take a course in "Axapta Administrator". Being a NAV-addicted myself, it was not really "cheese for my mouth" … as they say in Belgium.
What I still remember, is that everything is Object Oriented (in my opinion not really the best way to build business logic for ERP), many tools for different purposes (not one integrated development environment) … and extended datatypes … a very intelligent peace of art. And that's what I wanted to talk about.
Extended datatypes (ED) in Axapta is actually a custom datatype that you can define as a developer. Let me work with an example: Let's create an extended datatype called "edtDescription". For many (if not all) entities in an ERP application, you have to include a field "description". With ED, you would not give this field a datatype "Text" or "Varchar" … but "edtDescription", which was defined as (e.g.) Text 30 (which we all love(d) so much ). That way, behind the scenes, it would get the Text(30) as datatype.
But what is so nice about this?
I could change this ED. Suppose a customer wants it Text(50) … then I would just have to change it in one place: the ED itself. All fields that were defined with this ED would automatically get this new datatype definition.
What do you think … wouldn't that be great?
Hi Waldo. Yes it would be great. I worked on XAL and then Axapta for a few years before starting on NAV and there are quite a few things that Axapta did much better (for the programmers at least.) I am hoping that the NAV 5.1 and later versions will start to address this. Some things that I miss:
Layers that allow me to easily identify changes and roll them back. Where used in the IDE as opposed to a Developer's toolkit. Fields that do not thow an error if you try to assign a string that is too big. Error messages that get stored up and displayed in an info log. The ability to execute SQL code directly in the database. The list goes on and on...