Posts

Showing posts from March, 2011

AXBC Classes in Axapta

AXBC Classes in Axapta  (Axapta Business Component Classes) Ax /AxBC classes The Ax class is an X++ class that wraps a table to track state. An example of an Ax class is AxLedgerJournalTable. All Ax classes derive from the AxInternalBase class. From a service perspective, it is important to understand which elements that the consumer has passed to the service, so proper defaulting can occur. Ax classes share three common characteristics. They contain generated 'parm' methods that wrap all the fields on the table. When an incoming message is deserialized, the service infrastructure invokes each 'parm' method for which the consumer passed data. These 'parm' methods then set state and update the database table. Therefore, after deserialization, the class maintains the elements that the consumer passed to the service. This allows field defaulting to use the values the consumer passed. In general, the generated 'parm' methods are sufficient

Microsoft Dynamics Ax 2012 is coming...

This is going to be a major step forward in erp systems. 1200+ what’s new features Here are some to whet your appetite: • redesigned forms – a brand new look. • a form developed for the rich client can be used in EP just by publishing it. • migrates all reports to SSRS reports • forms can be reused. • aot can be accessed from Visual Studio. • new security structure is role based • trace can be invoked from the client • the new Tfs integration also supports work item • as and is key words are supported by x++ • more smoother integration between x++ and c#. objects can be just passed between both the languages. • different environments for development and application. • tables can be inherited • a lot of properties has been added to reduce setup through code. • rich use of powershell • a new command line utility called axutill is introduced Note: • the new version supports only vs 2010 • Oracle db is no longer supported • the rich client doesn’t supports windows xp • though th

The mystery of "index" vs. "index hint"

In the Axapta community, there is still a big confusion about the "index" and "index hint" statements used in connection with selects. So, what is the Axapta kernel *really* doing: Using "index": when you add the statement "index MyIndex", the Axapta kernel will add an "ORDER BY" with all the fields of the index. Example: select * from InventTable index GroupItemIdx will generate the following SQL statement to the database: SELECT A.ITEMGROUPID, A.ITEMID, A.ITEMNAME,.... FROM INVENTTABLE A ORDER BY A.ITEMGROUPID, A.ITEMID The Index ItemGroupIdx of the InventTable exactly contains the two fields ItemGroupID and ItemId (in that order). Using "index", you still give the control of which index to use to the database optimizer. So, if the optimizer finds a better index to use, it will use it. Using "index hint": when you add the statement "index hint MyIndex", the Axapta kernel will add a statement to instruct t

Cache in Dynamics Ax 2009

Many a time we have issue regarding data, on debugging found that old record is overriding new record… Sometimes it could be because the cache is not getting refreshed. Cache are used both on client and server. Microsoft Dynamics AX runtime manages the cache by replacing old record with new record are added to the cache. If one want to delete(or) clean up the local cache file, below are the following step: · Stop the AOS · Delete the ‘.auc’ file from location ‘ user\AppData\Local\ *.auc’ · Restart AOS. Scenario -  Suppose there are 2 AOS that required to flush the cache but then we cannot stop or start the AOS. How can one refresh the Cache? There are three menu action items that can be used to flush system data, the AOD, and dictionary. The thing about these though is that they are set to run at "called from" which when ran clear the client cache. The trick is to copy these three menu items, and then change the run from property

New features In AX 2012

AX6 sneak preview - SQL AOD (AxSYS.axmodel) A model is like a developer's layer in which he can keep his modified/new objects and import/export/delete in different AX environments just like we do in layers Dynamics Ax’s model database is stored in a Microsoft SQL Server database. The speed is back. Navigating the AOT is suddenly a pleasure again. Meta data heavy operations, like searching, completes an order of magnitude faster. For example; searching all methods on forms for any text completes in 2 seconds Dynamics AX supports a new file format: ax model-files. (extension: "ax model", example: "AxSYS.axmodel"). These are binary files, and provides the same deployment capabilities as AOD files did - and yet they are less than half size. Using a new tool you can import/export ax model files to/from SQL. You can also import AOD files into SQL. The compiled source is also stored in the database (as a blob) The labels are now also stored in SQL. We still support exp