Ax's white space aversion

I can think of a few places where I would like to output some nice white space to the end user, cushioning their existence from the vagaries of life...  But Ax 2009 isn't letting me:

• In table fields. I can confirm that trailing spaces are removed, which is a shame when you want to store pre generated rows of data that are to be exported to plain text files, in a host system that will then parse fixed length fields, padded with either zeros or white space.
• In the label text. Try as I might, that important white space from the right is cruelly taken away from me. My formatting and design of Ax forms is taken to new heights of frustration and anger. Well, perhaps I exaggerate a little after all we should be changing the margin fields and not manually adding spaces to the labels after the full colon.
• Directly in the editor, the white space is removed from the end of the lines.  It doesn't interfere normally, but when using the @ operator for strings it can upset your precious formatting.

Use the \n in strings to create a new line... And use labels.

I've discovered this aversion to trailing white space from Microsoft years ago ever since my Hotmail account's password used to have a trailing white space in it... And now it doesn't any more. Same password but minus the w/s. Is white space actually dangerous?

Problem of the slow loading customer invoice journal

The title makes this blog post sound like a Scooby Doo caper.

With the GLP-EE (Eastern Europe) patch installed in an Ax 2009 SP 1 instance we found that the customer invoice journal was loading slower and slower.  The form was nothing short of painful.  It seemed to be okay when working with invoices from Spain, Morocco, Italy...

After restarting both Ax and MSSQLServer instances it was time to roll my sleeves up and investigate with the SQL Server Profiler.  While you and I may still be an amateur with the tool a quick perusal of the output identifies the problem query.  After the restart of Ax I relaunched the profiler and immediately opened the invoice journal.  Finding the problematic sql can be difficult due to the use of sp_cursorfetch, hiding from us the original query.  The sp_cursorprepexec is eventually identified, and we can see the sql used in the cursor that is being reused all the time.

Next up was shouting at the silicon gods and then creating a new table index (CustInvoiceTrans) within Ax, to include a new field introduced from the aforementioned patch - RefReturnInvoiceTrans_W.

Maybe should have just added the field to the InvoiceIdx, huh?

With our new index we can compare query times and the difference is huge.

All that I can say is that Microsoft owes me a beer.