Tag: Dynamics NAV 2013

How to calculate Dimension Set ID

Starting from Dynamics NAV 2013, dimension’s structure has changed a lot. Since then, a lot of developers struggle to insert or update dimensions pragmatically.

I will not bother you with what was already explained a hundred times in other blogs on how to calculate Dimension Set ID. Better, I will share with you a simple codeunit “SpecDimensionManagement” that will save you time whenever you will need to update dimensions (by update I mean Create, Update, Delete).

In order to use my codeunit, I invite you respect the following example:

WITH SpecDimensionManagement DO BEGIN
// Get Current Dimension Set ID or init a new one
// Update my dimensions values
// Calculate my new Dimension Set ID
MyRecord.”Dimension Set ID” := GetDimSetID;
// Get new values if needed
GetCurrDimValues(DimCode, DimValueCode, MyRecord.”Dimension Set ID”);

I put some comments to explain what the functions do.

In the fob, you’ll find codeunit 92600 that handle the calculation and codeunit 92601 where I create some examples for test.

Feel free to contact me if you need more details / informations. Share your ideas and feedback in comment section 🙂

P.S: the fob is from a NAV 2015 FR (Build 49000) database. I test it on NAV 2017 and 2016 also.

This blog is available also on Microsoft Dynamics NAV Community

My two cents about Try/Catch in C/AL

By introducing NAV 2016, Microsoft introduced Try Functions to endow developers with some sort of Try/Catch in C/AL.

The purpose of this blog is not to add another entry to explain how to use Try Functions.  has already explained this here. The problem with these types of functions is resumed in this sentence from MSDN:

Changes to the database that are made with a try function are not rolled back.

So, inattentive developers may cause some calamities… You know what I mean 😉

Fortunately, Microsoft caught up by the introduction of NAV 2017. It added a new parameter DisableWriteInsideTryFunctions. It is fully documented here.

Okay, this is all good to know but what is the point behind this post?

To answer this question, I will first ask a question 🙂

How can we create a “Try Function” for older versions (5.0 to 2015)?

The answer is simple, and every NAV developer know it (should know it):

IF MyCodeunit.RUN THEN
MESSAGE(‘OK’) // Continue processing…
MESSAGE(GETLASTERRORTEXT); // Log the error or display it…

One of the biggest advantages drawbacks to me José is not having to use one new codeunit everytime we need to “trycatch” a process. This can end up consuming a lot of codeunits in some cases. (Yes, I quoted José and I made some modifications 🙂 ).

Here comes the purpose of my post. I would like to share with you a trick I used to use far away before NAV 2016. In fact, I created a Codeunit to centralize all processes that need a “trycatch”. It’s all based on this simple code (of course):

IF TryCatch.RUN(TempParam) THEN

“TryCatch” is my Codeunit where all the magic happens thanks to my temporary table “TempParam”. All you need to do; is to implement the function you want to “trycatch” inside the “Try/Catch” Codeunit and use it as I show in the “Try/Catch Example” Codeunit. Enough explanations, I believe the Codeunit is simple to understand. I’ll let you try and see by yourselves, download the objects here (fob and txt are from a NAV 2009 R2 database).

Of course, I’ll be glad to answer your questions if needed.

If “TempParam” trick does not suit your need then create your own solution (share it as comment if you want). You can for example create global variables inside “Try/Catch” Codeunit and initialize them by calling a function “InitMyGlobals” before you call TryCatch.RUN.

P.S.: In 2014, Vjeko explained why some sort of Try/Catch may be a big disaster for C/AL world (or at least, if not used wisely).

This blog is available also on Microsoft Dynamics NAV Community


Theme by Anders NorenUp ↑