Beware the “Catch”

Recently while debugging some legacy code I came across the following interesting observation regarding transaction scopes (ttsbegin, ttscommit) and the exception handling surrounding it. While walking the legacy code was observing very strange and unexpected behaviour and after some online investigation i found the following statement from Microsoft:

“When an exception is thrown inside a ttsBeginttsCommit transaction block, no catch statement inside that transaction block can process the exception. Instead, the innermost catch statements that are outside the transaction block are the first catch statements to be tested.”

In its simplest form this means that for the following code:

Prints the following results:

Now when it comes to a simple block of code like above one may say “Well that is simply silly coding”, however it becomes harder to anticipate results when that inner try…catch is within a method somewhere deeper inside the call stack (perhaps in standard code somewhere) e.g.

Further more if your inner exception does cleanups or logging of information this will not happen by carelessly adding ttsBegins and ttsCommits around the calling code E.G. “writeErrorLog” will never be called in the following function regardless of what the writer of “innerFunction” does if the writer of the caller adds TTSBEGIN AND COMMIT

I thought I would just paste these observations for anyone who like me has experienced this type of “strange behavior” in the past and didn’t know the exact reason and also as a warning to beware of the “Catch”.

Feel free to share your comments, observations and thoughts.





Advanced AOT searching

Its always a great opportunity to interact with other AX developers and have the opportunity to learn from each other. A few weeks ago I published a blog post on searching the AX AOT in code for objects with specific properties, after the post went out I got a comment on the post of a much easier way to search the AOT from the frontend, that for some reason I have never really noticed before. So here is a quick way to do an advanced search of the AOT using a real situation I encountered this morning.

Example: Find all privileges in the AOT that have a specific menuitem as an entry point. e.g. “PurchFormLetter_PackingSlip”

1. Open an AOT and select the section of the AOT that you wish to search. Obviously the narrower the search the quicker it will be. I selected Security->Privileges.
2. Right click on the object. Click Find
3. Select “All Nodes” in the search dropdown
4. Select properties tab.
5. Right click on any field in the “Property” Column, Click filter by field.
6. Enter the name of the property you wish to search on. In my case I’m looking for all entry points that points that have the ObjectName set to PurchFormLetter_PackingSlip, so i enter “ObjectName”
7. Click Ok.
8. Click the “Selected” checkbox
9. Enter the value you want to search for under “Range” e.g. “PurchFormLetter_PackingSlip”
SelectProperty210. Repeat steps 5-9 if you want to search for multiple properties.
11. Click Find now
12. You will now have a list of all the subobjects of whatever you selected in step 1 containing a specific property with a specific value.


Note 1: You can also do some pretty neat searches using both the date and advanced tabs on this form so be sure to check them out too.

I hope this helps somebody who like me has just overlooked this for years.

Thanks Martin for the tip!


Disclaimer: For my specific example it may have been easier to use either the Security development tool or right click on the menu-item in AX -> Add-ins -> Security Tools -> View related security objects. But I needed an example for this post :-)

Find all Menuitems Linked to a Form

For diagnostics purposes it is often useful to search the AOT for all objects matching cetain properties. For example you may want to find all display menutitems that are pointing to a specific form. The below job illustrates how to simply traverse the Display Menuitems node in the AOT to locate all items who’s “ObjectType” is “Form” and object is a specific form name. E.G. “PurchReqTable”.



Adapting this to search other nodes is as simple as changing the original node instantiation to search a different path as well as changing the AOTgetProperty() method to search through the properties relevant to you.

Happy Daxing

Original community post:

8. Locate specific AOT object without scrolling

As part of my series on “Things new X++ Developers Should know”. I have been writing a few basic howtos for new X++ Developers.

Today’s post relates to quickly navigating to specific objects in the AOT without endless scrolling.

So often when working over the should of new developers or consultants exploring the AOT I see them scrolling endlessly or dragging the scrollbar back and forth for a while before finding the object they are looking for.

A common technique to navigate through lists in both Windows (e.g. My computer etc) and windows based environments (SQL management studio etc..) is to simply start typing the name of the object you are looking for. Windows automatically moves to the first object matching the sequence typed.

AX is by no means an exception to this rule. Simply click and expand the main node of the object you are looking for e.g. “Forms”
AOT Navigation Forms
and start typing E.G. “PurchReqT…..”
As you type AX will move to the first object found matching what you have typed so far..
E.G. P moves to PartitionAdministration,  Pu to PurchArgreement etc….

There are some bonus features when using this in AX:
1. You can always see what you have typed so far by looking at the bottom left of your screenAOT_Navigation_Status_Bar
2. The typing timeout is long compared to applications like SQL etc where you need to have taken a speed typing course to get this right. As long as you still see the search term in the bottom you can just continue typing (this normally takes around 7 seconds or until you use your keyboard arrows or mouse to do something different

I know this may be a very obvious tip, but I’ve witnessed too many people taking forever to find objects by scrolling to not include this in the “Things new X++ Developers Should know” series.



Things new X++ Developers should know

developer-iconSince my start in X++ development over 6 years ago there are many small things that I have learnt that I wish I had known from the start. Small things that won’t necessarily help you post a stock journal from code or perform complex integration tasks, but none the less makes your day ever so much more productive. If you are a seasoned developer you will most probably already know most of these, but I thought I’d put them all down in a neat list for new guys to go through. Here are some of my favourites along with links to short articles on how to do them. (I will hopefully add some more over time).

1. Keyboard Shortcut to view properties of an AOT element: Simply Hit “Alt+Enter” on any AOT element to view its’ properties list. Much quicker than fumbling with right clicking on the mouse. (view more shortcuts)
2. Drilling down to the AOT from an open form: Instead of reverse engineering forms from menu structures or navigating in the AOT to edit a specific form, simply right click on any form, click “Personalise”, select the “Information” tab, click on the “Edit” button next to the form name. (view details)
3. Drilling down to the dictionary type of an object in the AOT. E.G. Edit enum or EDT being used by a field on a table. Navigate to an element in the AOT e.g. A enum field on a table. Right click on the element, click “add-ins”, click “Open in new Window”, click “Open used Enum” etc…. (view details)
4. Drill through to code from Info log – Quite often the info log will allow you to drill down into the code the called the error message. If you notice a small arrow on the error icon you can simply double click on the line to take you to the code. (view details)
5. Infolog code drill down does not work if code is running in CIL. As an addition to the above you will not be able to drill down to code if it is running in CIL. For DEVELOPMENT/DEBUGGING purposes only you can simply disable code from running in CIL in your User Options.
6. Run AX as an alternative user. For debugging security or processing workflow it is often needed to run AX as an alternative user. Simply press Shift and right click on the AX icon on your desktop. You can then select “Run as different user”. (view more)
7. Determine Field name from control on Form. Sometimes you need to quickly find out the database table and field that is shown on a form without navigating through the complex AOT form. Simply right click on the field, click “personalise”. Under “System Name” you will see the following: Control name, Datasource Name, Table Name and finally Field Name. (view details)
8. Locate specific AOT object without scrolling. This may be an obvious one as Windows uses this technique in many other applications. Open the AOT and expand and click on the main node of the object you are looking for e.g. Classes. Then simply type the name to navigate to the specific object. (view details)
9. Creating an Development Environment shortcutAs a developer you don’t necessarily want to login to the Dynamics AX front end whenever accessing the AX shortcut, but rather want to open a development workspace directly. To do so right click on the AX shortcut on your desktop, click properties, on the shortcut tab in the “target” field add “-development” after the path to the Ax32.exe file. (View step by step)
10. Enabling breakpoints / debugger. One of the most important tools in a developers toolbag is the debugger. There are a few items on the checklist that you should ensure before you can successfully debug code: View them here.
11. Enabling viewing of Layer and Models. In a complex AX environment it is very useful to know what model and layer an object forms part of in order to search for patches or fix yourself. You can easily enable the AOT to display these by navigating to: File -> Tools -> Options -> Development -> Application Object Tree -> Application Object layer -> Select “Show All layers” and Application Object Model -> “show on All elements”.
12. AX Layer Config files. Create AX shortcut files to allow you to easily logon to the layer of your choice. View how here. (link available soon)
13. Profiler / SQL Trace. You can easily make use SQL Tracing or profiler to see the exact SQL being executed behind the scenes. This can be very useful for debugging purposes. (link available soon)
14. Using Alt+[Up/Down] keys to reorder AOT elements. To rearrange object elements like controls on a form grid simply hold in ALT and press the Up and Down keys to rearrange its order in the parent. (view details)

Anyway thats my list for now. Please let me know of any other quick tips and tricks that you think new developers (or old) should know about!

Keep a lookout for some more detailed explainations on some of these coming up in the follow days.

For some more advanced tips, tricks and coding patterns please also checkout the knowledge base at


Active Directory Lookup in AX 2012

As you may be aware by now, AX allows one to create users of type “active directory group” which if setup will auto-create users who belong to that group when they try to login. Furthermore users (whether auto-created or manually created) who belong to these groups will inherit the security permissions assigned to these groups.

One challenge however is, to debug this. I.E. Finding out which users are members of specific groups or what groups a specific user belongs to. My previous post was about how to determine ownership via command line. After a bit of reflection I thought this may be better and more useful to have this functionality directly within AX. Using Attached is an XPO with the relevant code (use at your own risk).

Screen Shot 2014-09-08 at 12.37.46 PM


Basically it adds a class to AX as well as a lookup menu item to UserListPage form and the User form.

Please let me know your comments.

Here is a sample job if you don’t want to download the full project. It prints all groups for a user.


Determine which users have outdated AX client versions

Problem / Symptom: You want to ensure that all your users’ Dynamics AX clients are updated to the correct rollup.

Description: You may have recently upgraded your Dynamics AX Kernel or Application to the latest Cumulative Rollup (CU), you’ve applied it to all of your AX Client installations that you are aware of but you would still like to make sure that nobody is logging into AX on an old version and potentially causing some problems. You may also be receiving an error in your AOS event log that goes something like this

Object Server 01:  Internal version mismatch. Microsoft Dynamics AX client from [MACHINENAME] ( tried to attach with 6.2.1000.4051 revision of kernel.

Solution: (Applies to AX 2009 & AX2012) There is quite a simple solution to this issue.

  • Open up any Dynamics AX client connected to the AOS in question.
  • Navigate to System Administration -> Enquiries -> Users -> User log
  • Right click anywhere in the grid, click personalise
  • Click “add fields”
  • Expand “User log”
  • Select “Build number”, Click Add

Screen Shot 2014-07-25 at 4.02.20 PM

  • Close the Select Fields form
  • Close “Personalise Form”

Your User log form will now show all sessions and their build number. You can now browse and field all sessions that don’t have the same build number as your kernel. You can also further filter this form to only show the non matching records by right clicking on the Build number field and entering “![buildnumber]” (see screenshot below)

Screen Shot 2014-07-25 at 4.08.14 PM

Click on the “General” tab to find out which computer/workstation the invalid session was coming from. You can now go and run the updates.

Screen Shot 2014-07-25 at 4.10.02 PM

Running Dynamics AX as an alternative User – Quick Tip

Problem / Symptoms: Users need to test Dynamics AX setups as different users.

Description: Quite frequently we are finding the need to test/run Dynamics AX as a different user from our default login user but do not want to run multiple remote desktop sessions or have to log in and out of our current session. We may need to do this for a number of reasons e.g. Testing a workflow approval process i.e. login to approver as the relevant user, Testing security permissions, Testing SSRS permissions, getting screenshots of AX for documentation with a different profile etc…

Solution: There are a number of ways to do this, I have been using CMD/DOS scripts to do this for years (more on this below). But I just found the simplest trick in the book:
1. Locate a shortcut (won’t work for config files) to Dynamics AX,
2. Right click, if you’re lucky (depending on operating system) you will see a “run as a different user”. Select this option, enter your user details and AX will run as this alternative user
3. If there isn’t a “run as different user” option, simply hold in shift and then right click, you should now see the “Run as different user option”

Run as different User


Alternate Solution:
If you are running via config files this solution will not work, you will need to first create an AX32.exe shortcut that takes the config file as a parameter E.G.

You can also create a .bat file with the following code: