Thursday, January 27, 2011

Will Dynamics Ax 2012 support Windows XP?

The Technical Conference 2011 has ended. The dust has finally settled down. Session content has been tweeted. Details probably have reached a blog near you.

I did my fair part of reading, going through tons of information regarding the new release of Microsofts ERP flagship.
What seemed only a minor detail I found particularly striking:

  • Windows XP is no longer supported by the rich client. (Source: Casper Kamal)

Now I'm a frequent reader of his blog, which has excellent content btw. This statement about Dynamics Ax 2012 surprised me. I could not yet get it confirmed by other sources though.

Why I found this surprising?

First of all, Windows XP is still market leader, looking at usage. What about this little statistic, depicting current usage shares of operating systems?

Businesses around the world never liked Vista, kept their money in their pockets and waited for Windows 7. Windows 7 was most definitely a better release than Vista, but when it finally was available, people were so used to their old system it was and still is very hard to let go.
Earlier on, Microsoft even extended support for Windows XP up until 2014. Now is this issue delaying the introduction of Ax 2012, or speeding up replacement of Windows XP?

What about 'gnath'?

I've been in IT all my professional life, quite a few years with Dynamics Ax aka Axapta. And still learn new things, still discovering.
Like the other day, when I was doing research about an Ax table called NumberSequenceGroupRef. There it was, in it's properties as Developer documentation: Gnath.

No idea what that word means. Google couldn't help me either (nor Bing). The closest I got was a medical term, or something with biology. Or is it an acronym? But for what?

Have you got any input on solving this mystery? Please comment!

Sunday, January 9, 2011

How to use some of the lesser known methods of the SysQuery class

When working with ranges for a query, you may have used the SysQuery class already.
With some of the methods in this blog post you can live without, but they sure can make your life as a programmer a bit easier.

Some examples. We gonna use a querybuildrange, setting it like this:

QueryBuildRange myQBR;

Now we set the actual value for the range, by using this format:


This method takes a string as argument.
But if you are not sure which type your argument is gonna be, you might wanna do a conversion to be on the safe side. It doesn't hurt to make a habit of writing your code like this:


Hey and what about that other method from the Global class, QueryValue? No use of that?
Maybe you are used to writing something like this:


This converts the argument (anytype) to a string as well. Actually, this is equally good, as this method calls SysQuery::Value().

Logical NOT

If we wanna list all the customers that do NOT have the currency EUR set up, we can do something like this:


The SysQuery class comes to the rescue here as well, by providing the exact same functionality


Check it out, this method converts the argument to a string AND adds an exclamation point in front of it.

No range value

If you range has been set up, but you don't want to apply anything yet, you can provide an empty string as argument. This way the query will retrieve all records.


Again, SysQuery has something in its toolbox for us as well:


Coming from the documentation in the code:

Used when you want to have a completely open range, no limitations; "a blank range"
use this method for future compability

Don't mix this one up with the method valueEmptyString. The method valueEmptyString will retrieve records with no value for the specific field.


And this one of course has an opposite, valueNotEmptyString


This will retrieve records where there is a value set up, so no null values.

To end this post, maybe the method that saves you from writing code the most: Range.
We can set ranges from/to with SysQuery class as well.


The method will add the dots ('..') when appropriate, so something like this:


Like stated at the intro of this post: Nothing lifesaving, but nice-to-haves.

Friday, January 7, 2011

How to quickly create a project with all objects of a specific layer


  • When investigating code in Ax, it may be useful to get a quick overview of all the code in a specific layer.

  • When you intend to move code from one layer to another, you may need a list of objects in a specific layer.
Follow these steps in order to get a solution for both challenges with ease:

Step 1: Create a new project.

You can rename your project as desired, we'll call it Project_USR_Layer for now. Then open the newly created project.

Step 2: Choose Advanced Filter/Sort from the toolbar.

If you are into keyboard short-cuts, you can use Ctrl-F3 for this as well.
A new dialog pops up.

I like my objects grouped in the project as they are grouped in the AOT, so I've chosen Groupings - AOT.

Step 3: Select the required objects.

Use the Select button on the dialog to select the objects you require for your project.
We wanna select all AOT objects from a specific layer, so we'll use the UtilLevel field in the selection criteria.

From the screenshot you can see that all objects from the USR layer are selected. If desired, you can limit the type of AOT objects for your project as well, by using the recordType field.

Confirm twice and the objects are added to your project. This may take some time, so be patient :-)

Similar challenge:

You can use the same method for selecting AOT objects modified/created by a specific programmer. Just set different selecting criteria in your query.

How to display records from different company accounts in one form

One of the previous posts on this blog discussed getting records from different company accounts with one select statement. For this, the crossCompany keyword is used.
Now we'll do something similar, but this time we'll display the records in a form. And the good news is, it's really easy. All ya have to do, is set a property on the datasource of the form.

You can use the crossCompanyAutoQuery property, located on the forms datasource. Standard value is 'No', so set it to 'Yes'.

But what if we want to filter on selected, different company accounts, doing so by code?

We would use the dataAreaId field of the table for this. For example, by adding following line of code in the init method of the datasource, right after the call to super:


If we open the form, as a result, we get an error though:

Filtering at the data source level is not allowed for a cross-company query.

Mmm, inconvenient.

Any workaround? Must be, as you can filter by the dataareaid field manually in the form.

Here is a short piece of code that does the trick:

Query myQuery;



Place the code displayed above right after the super call in the run method of your form for example, or call it by pressing a button. (Just make sure you use executeQuery after setting the ranges.)

As you see from the code sample, we're using addCompanyRange to set the required company accounts as filter in our query. You can call it multiple times, they are accumulated as OR statements.

Monday, January 3, 2011

2010 Year End - ERP failures

At the end of a year, all sorts of lists pop up. The media bombs us with top selling albums of the year, the world's richest billionaires and ... the biggest ERP failures of 2010.
Yes, it 's true. Now and then, an ERP implementation fails. Sure, most IT projects end up being late and over budget. But when its by a factor 4 or 5, it fails. Big time.
Sometimes the GO LIVE milestone is even never reached. Or only when the original scope was changed so badly, the customer, vendor or integrator could not recognize it any longer.

I can't help but notice that the name SAP comes up more then once in this story. But no chuckles from me, a Dynamics Ax fan.
When the new accouting software of your uncle's Bob grocery store isn't quite what was expected, that's not big news. But when the city of New York is modernizing it's payroll system, where talking different numbers and headline news.
SAP is simply more active on the upside of the market, aiming for bigger customers. When those kind of projects are not a success, it's news. Simple as that. As a defense, one can argue that the mentioned failed projects are not all 2010 based, some are "old news" to say the least. But is there something we can learn from the article, even for people with no connection to SAP whatsoever?

Some highlights from the original article on ComputerWorld:

Customers have to plan well, budget enough money for training and evolve their usual way of working.

No arguing there. This goes for all customers: small, medium, large and very large.

XYZ used the project as "a trial-and-error training ground" for inexperienced employees.

Haven't we seen this happen before, where a rookie employee of the integrator is sent out to the customer to get results. Just to make sure the new guys hours are billable from day 1 on the job.

As a customer, ask for references before you start the project. Get the team member list of your integrator, with the years of experience of each consultant noted before you sign the contract.

XYZ used a "fake" product demonstration to trick it into believing its software was a good fit.

How many customers still buy a product (or software for that matter) based on a Powerpoint presentation? If needed, involve a third party to help you judge product demo's. Make sure the demo is customized to your business, your processes.

The customer didn't "timely and accurately define its business requirements" or provide "sufficient, knowledgeable, decision-empowered users and managers" to the implementation.

When things do go wrong, how many customers are up for self-criticism? Did they do everything within their might in order for a successful implementation? There are two sides to every story...

The article made me remember this other news headline from last year, the lawsuit Oracle filed against TomorrowNow. After the ruling everyone agreed the 1.3 billion dollar awarded was out of proportion. Did it make other parties in IT nervous as well? Because when an IT project fails and the partner is fired, someone else has to step in. Giving the new partner access to the original documentation, or even maybe the original code. When only the partner is replaced, not the product.
Wait and see if 2011 brings more of the same.

A different view

A different view on some of the more recent posts on my blog, with credits to the folks at Wordle.

Looks like it's all about Ax...