I’ve been asked to reiterate some arguments against direct access to AX business data. (As you all know, the recommended approach is always going through AOS, such us calling web services.)

Here are some of the arguments:

• You would bypass all business logic. It often means that you would have to re-implement some AX logic (and risking getting out of sync with later changes in AX), or you could miss some important logic completely.
• You would have to deal with many AX concepts normally handled by AX kernel – partitions, virtual companies, table inheritance, date-effective data and so on.
• Lots of AX metadata is in AX application, most importantly table relations.
• You would bypass all AX security.
• If you wanted to write data into AX database, you would have to deal with record IDs and potentially other system fields.
• You would bypass data caching and AOS servers could ignore your changes, because nothing told them to invalidate their cache.
• The exact schema in database is considered an implementation detail (because nobody should touch it) and can change without warning (for example, remember the change in implementation of table inheritance between AX 2012 R1 and R2).
• It’s not a supported use of Dynamics AX and therefore Microsoft wouldn’t help you if you got into troubles with your database.
• And so on…

My advice is: if you decide to read data directly from database (likely because of performance reasons), you see you have many things to think about. Be careful, especially regarding security.

If you want to write into AX database, just don’t it. Use AIF, put the data into another database and let AX read them or something. Changing the AX database is simply too risky.