Eric's Tech Blog

A coworker sent me an email today asking about a SQL query for returning results based on the value in a setup table.  I sent him the correct syntax and then inquired as to the purpose of this.  His response was that he had a request from a customer to filter the item lookup on the sales line table based on a setting in Sales & Receivables Setup.  He was going to use a table linked to a view, which among other things would be rather messy.  I then proceeded to show him the following method for creating a filtered lookup. It is a little known fact that code in the OnOpenPage trigger of a lookup page is executed when the lookup dropdown is displayed. Here is a lookup to the item table in a Cronus database. Now, let's say we want to filter to just items beginning with "11".  We could add this code to the OnOpenPage trigger of the Item List. Now the lookup returns this. Now, what if we want to make it conditional?  In this case, the fi...

NAV's consistency function is seldom used but very valuable when you need it.  Simply put, it ensures logical integrity at the transaction level.  This means that when a transaction is committed, it has followed any business logic that you wish to enforce .   That last part is important.  It is up to the developer to determine which conditions make a transaction consistent and then set the consistency flag at an appropriate spot in the code.  The use of this function does have one major drawback: it is anywhere from difficult to impossible to track down the source of a consistency error using the debugger.  Because the source of a consistency error depends on what may or may not have happened during the course of the transaction, the best way to figure out what went wrong is to look at the data that got generated at the state it was in right before the commit. If only there was a way to do this... Step 1: Create a debugging instance. First, crea...

I have been developing extensions for Microsoft Dynamics Business Central for a while but I had never attempted to publish one in the wild until now.  Of course, I didn't start with something easy - can't have that now, can we?  No, I did one with an upgrade process to pull existing data from a legacy C/AL customization into an extension.  It was pretty straightforward until I went to put it onto the production server and I was greeted with this: This was a pretty easy one to get past.  I was developing on 2.1 but I was able to set the runtime value in my app.json to 2.0 and still compile.  Since this is a minimum value, it's probably best to leave it at that unless you know otherwise. Also, a note about the license incompatibility message - that's apparently a known bug.  You can ignore it. On to the next error... If you're deploying to AppSource, you will want to sign your extension but for an on-premise installation, it's not necessa...