The total, internal size of the records in your joined SELECT statement is 25980 bytes, but Microsoft Dynamics is by default performance-tuned not to exceed 24576 bytes.

The total, internal size of the records in your joined SELECT statement is 25980 bytes, but Microsoft Dynamics is by default performance-tuned not to exceed 24576 bytes.

It is strongly recommended that you split your table(s) into smaller units.

Alternatively, you have to specify a ‘Buffer size’ value of 26 Kbytes or higher in the ‘SQL’ tab page in the Microsoft Dynamics Configuration Utility. The default value is 24 Kbytes.

Exit Microsoft Dynamics immediately, and follow the directives above. Use of the table(s) will cause unpredictable results.

Cannot select a record in Purchase orders (PurchTable). Purchase order: , .

The SQL database has issued an error.

Cannot select a record in Purchase orders (PurchTable). Purchase order: , .

The SQL database has issued an error.

Hi Nagendra,

There are two solutions:

  1. Try increasing Max Buffer size in AX 2012 Server configuration utility > Database tuning tab (or)

  2. Limit the number of fields returned by the query

  • Fayaz

I can agree, that’s a perfect answer from Fayaz.

I would suggest you to do the increase of buffer size as a priority, because you will keep on getting this kind of error again as you will be customizing your AX. As soon as you start the Sales/Purch order table/form development (let’s say by adding more fields into form, adding more joined tables etc), or let’s say if you modify and extend the SalesInvoice, you will run into this problem again quite soon and it won’t be always that easy to follow the field count (and size) in all the forms and reports which you modfiy.

We doubled the buffer size and haven’t encountered any side effects so far. I don’t say you have to double it, but 35 kB could be a good start.

I have discussed this at great length on here and with my colleagues, it is not advised to increase the size of the buffer as it can cause instability throughout the system, and can take resource else where.

However, that being said there is not much else you can do except reduce fields used in the query, which then means you cannot query on the fields you require.

I guarantee if you develop any SSRS report with 5+ tables you will come across this error, I am still searching for a resolution, the only definitive one so far is increasing the buffer, but again this is not advised as you are going against setup done by Microsoft.

I would like to chat to anyone who has ever come across any provable problem caused by a minor increase of AX AOS buffer (from 25 kB to 35…40 kB). My feeling is that everyone talks about it just because Microsoft has mentioned this “25 kB limit” in their technical documentation, but up till now I haven’t seen any real life example where this increase has caused any problems.

Without increasing the buffer size, it will become really difficult to work on some development tasks as you might have to add up to your task estimation the time required for a possible research of “unnecessary” table fields and disabling of those fields (you will literally have to take a look into, let’s say, SalesTable and decide, which of the existing fields you don’t use and whether they can be dropped, so that you can free up the space for your new fields).

I do understand the importance of optimisation and of having as little information as possible transferred between DB, AOS and Client… this is all cool and great. But to mess around with few tables trying to decide which of the standard fields are ok to stay and which should we drop to free up the space for our own fields, in order to keep the buffer size at most to 25kB and not to increase it a little bit, to let’s say, 35kB - to me that all does seem a bit ridiculous. In XXI century where hardware progresses so much, where networks can handle more and more bandwidth, it does seem a bit strange that we have to decide which of the 2 or 3 fields in SalesTable should we drop, because our latest edition Dynamics AX cannot handle few more fields… this makes me mad, sorry :slight_smile:

In response I’ve been told by a senior developer who works for one of the leading Gold Partners in the UK, that they changed this for a client on one occassion only and will not do it again. They noted lag elsewhere in the system when running reports after changing the buffer.

I am only going by what an experienced developer who has experienced issues after changing the buffer has said.
I have actually changed them on my own local dev system and my dev system works fine.

We have several AX2012 environments running with 48 kB buffer and to be honest, I haven’t noticed any performance decrease at all. Unless something noticeable comes up, I don’t see a need to decrease the buffer size for now.

If I recall correctly then already with a standard SalesTable form with enabled “Process manufacturing” (and probably some other standard functionality), the “exceeded buffer” error was coming up in a clean standard AX 2012 system as soon as you tried to open a sales order in details form… I have been working with AX 2012 since March 2010 (in Microsoft TAP program initially) and I honestly don’t remember to have worked with any AX 2012 system for which the buffer size wouldn’t have been increased at some point. It is a bit irritating that some of the standard functionality in AX 2012 is already working literally on the very edge of this buffer size. I don’t see a way to totally avoid the increase of buffer size unless you spend some time on the standard system looking for unnecessary standard fields which are ok to be dropped (by applying DEL_ config keys) in order to free up some buffer space for your new fields.

I’ve already said;

"I am only going by what an experienced developer who has experienced issues after changing the buffer has said.
I have actually changed them on my own local dev system and my dev system works fine."

So far we are still experiencing the same issue and I agree whole heartedly with you Janis the only way to resolve it is to increase the buffer, but again “I am only going by what an experienced developer who has experienced issues after changing the buffer has said.”

Not my words, an experienced developers.

Yeap, I got it. You know, I’ve been in AX development world for almost 7 years, so I can’t really call myself unexperienced :slight_smile: All I wanted to say is just that I have quite a different experience with this buffer increase issue, which is opposite to your colleagues experience… I wouldn’t recommend not to increase the buffer size (at least a little bit, up to 40 kB).

It is best of all for everyone to try it out for themselves and run the system for a while with increased buffer size and see what happens. It might be that different hardware setup has something to do with different experiences.

Hi Nagendra,

Just to add .02 cents to this excellent post -

Traditionally MS cautioned against making any changes to the buffer size. There were quite a few articles from MS on this subject suggesting alternatives(Ex - http://blogs.msdn.com/b/emeadaxsupport/archive/2010/05/10/binding-operation-failed-to-allocate-buffer-space.aspx)

But I have seen quite a few customers with changed buffer size working without problems. And I have heard MS Support Engineer saying similar things (i.e. they have customers with this change working fine).

Coming to your issue -

  1. Under the hood, AX reserves the system memory to 24K (default).
  2. The error message you have received is asking to increment by 2K

In my opinion, you can go ahead and make this change.

Yeah it seems to be hit or miss, the problem I have is I’ve created a multi-table SSRS report which uses an AX 2009 query, I need around 48kb on the buffer, and every field is required - so really I have no option but to either increase buffer over double, or to create the report in the 2009 report builder - which is pointless as it can’t be used in 2012.