Most of the development teams tend to neglect this significant area of performance optimization and procrastinate it until the end of development cycle. Many jobs that you might be able to execute rapidly in your development machine might crawl when it’s deployed and exposed to a plethora of requests from users all over. This is why it is significant for the developer to write code adopting the performance friendly strategies rather than relying on the naked eye to justify performance and speed.

One such area that I would like to cover today is the round trips between client and server. Mostly in development machines the AOS is installed locally which is why the developer is not exposed to the drastic consequences of excessive client-server round trips on overall performance.

Few of the commonly used techniques that can help reduce these round trips are :

  • Caching the display and edit methods
  • Using the Runbase classes to support marshaling of parameter dialog forms between the client and server
  • Proper indexing and caching

In this blog, we would be discussing the first one.

What is a display method?

Such methods are generally consumed at form level and they render data based on some calculation/manipulation

What’s so evil about the display method?

Well, for each of these methods run individually. For example you have a grid of 30 records and there in you add a column that is based on a display method. In this case there will be 30 individual calls to the server to fetch data. Also, whenever the form is refreshed all of these calls are made every single time that can kill the performance.

How to address this issue?

You should make use of caching. This can be done by using the CacheAddMethod on the  FormDatasource. This method enables the form the calculate all of the display methods in a single round trip to the server rather than making individual calls.

How to use the CacheAddMethod?

Override the FormDatasource init() method and add the following code:

public void init()



// name() is a display method in the CustTable. This method is the //init method of the form datasource.

CustTable_ds.cacheAddMethod(tableMethodStr(CustTable, name), false);


AX 2012, introduces a new feature called the Declarative Display caching. This allows you to enable caching by setting the form control property CacheDataMethod. There are three possible values:

–          Yes

–          No

–          Auto: equates to yes on a read only form datasource. If there are multiple controls where this display method is used and anyone of the control has the property set to yes. Auto would also equate yes in that scenario.

You must write the display method at the table level!

Caching cannot be used for display methods declared at the form datasource level. The reason for this is that these methods require access to the form meta data to exploit caching.

All of the points made above are equally applicable to edit methods too. I hope you would take care of these points the next time you make use of a display method. That’s all for now, I hope you had a learning experience while reading this blog this. Thanks and have a good day!


Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Comments