Extended Datatypes


Time to do some philosophing… Smile.


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 Wink).  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?



Comment List
  • 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...

  • That would be very good, but it would also be needed to define globals/locals as that datatype. Or for the moment to define a global/local AS Item.Description.

    So when the description of the item changes, all globals/locals based on it change. This is something I had with Progress and I do miss it a lot in Navision.