In Dynamics AX 2012, if you are running a query with too many joins you can get an error or warning message saying “The number of joins in the statement is XX. This exceeds the maximum of 26. Turn on exception for this warning to see the call stack.”
So what is this, and what can you do about it?
When buying microcontrollers, breakout boards and the like, they often come without headers.
In order to plug these boards into a breadboard, we’ll have to solder some headers on to them. Doing so is quite easy.
Most boards have 2.54mm pin spacing, so if your board did not come with headers, you’ll find suitable header strips in almost every electronics shop. Look for something like this: https://littlebirdelectronics.com.au/products/40-pin-header-terminal-strip
These strips snap off easily to the desired size, just double check that you have the correct number of pins before you snap. As an example, Adafruit’s Huzzah ESP8266 breakout board have two rows of 10 pins each, in addition to 6 pins for FTDI.
After having worked in different IT departments for 30 years, one of my standard quips is that our job is to ensure that the network doesn’t turn into a notwork.
Now it seems that there is a new need for that term “Notwork”, and it’s related to the so called “Internet of Things”, or “IoT”.
I have several of these electronic devices around the home, measuring temperature, controlling lights, measuring power consumption, etc., and they all fall under what people will call Internet of Things.
However, not a single one of these devices are on the Internet… In fact, the wireless network they connect to is not even routed to internet, it is a completely separate network only communicating with my device management server.
So I have decided to call this a Network of things, or Not. OK, I just know that is not as catchy as internet of things, and I’m going to have a hard time selling the idea of calling it “Not”. And if I ever start building and selling devices commercially, it is going to be tough convincing people that “notwork” devices actually work…
However, that’s a worry for another day so there it is, I proudly introduce the notwork.
Occasionally we need to run updates or inserts of large numbers of records, something which has this nasty habit of taking out locks that will prevent other sessions from updating or inserting in the same tables. Also, if we terminate such an operation, we’ll have to start all over again from the beginning, wasting a lot of time.
Luckily, with Read Committed Snapshot Isolation which is supported by AX, readers will not be blocked by writers, but writes will still be blocked by other writes. Once SQL Server escalates the row-level locks to table-level locks things start to go downhill rather quickly, and as we’re pretty much guaranteed not to have an outage window in which to run the update operation, someone is going to be on the phone soon. Quite soon…
The solution is to break the operation into smaller transactions.
Continue reading “Implementing checkpointing in long-running updates”
From time to time it is necessary to develop custom .NET code and call it from Dynamics AX. It could be that you already have the .NET code to do what you need and you don’t want to reimplement the functionality in X++, or what you are trying to do is too complex to do directly in X++.
One common situation is where you need to write a wrapper around some operating system functionality or web service to expose a much simpler API to AX.
This works, and AX has good support for calling .NET code through it’s .NET interop framework. One thing that does become more complicated is debugging, but once you know how it is actually quite easy.
Continue reading “Debugging .NET code called from Dynamics AX”
