Yesterday I was going through various Dynamics NAV blogs and found a very interesting article about error handling. Over past few weeks I was planing to write a article about error handling and however it always got delayed due other topics came up with Microsoft Dynamics NAV 2015.
I have created my own codeunit and within that I did not wrote any code line ( Blank codeunit) and saved it as “Codeunit to run”.
Having that in my mind I ran my codeunit and here it goes!!
The following C/AL functions are limited during write transactions because one or more tables will be locked. Codeunit.Run is allowed in write transactions only if the return value is not used.
What it basically means is that we cannot use the return value of the code unit.
Why is that? If you check the code lines, as soon as the first line get executed, Transaction get started implicitly because first line is a write transaction. In the very next line, codeunit throws an error. In this line we have written and restructured our code to execute and continues even IF the codeunit execution fails.
That is where the problem is.
Normally what happen in NAV is if there is ANY error during a transaction Dynamics NAV automatically roll back all the changes happened during that transaction (Simple and easy).
So if we execute this code segment what will happen to the database changes occurred during our code execution? and which database changes should rolled back? Only those happen inside of the codeunit or all the changes happened before entering into codeunit.
To make it simple for everyone Dynamics NAV asked you to restructure your code to avoid this kind of complexity and avoid you to use returns values of a write statement.
As a example if we have 5 successful transaction line and in the next line it failed and what we should do?
Should we allow to commit above 5 transactions or should we rollback all those 5 transactions?
As VJEKO, rightly mentioned in his blog, try catch is easy if we have no transactions. Once the transaction enters to the arena you will end up in a real mess of deciding which should commit and which should not commit.
As VJEKO, mentioned there are solution to that by controlling transactions directly and introducing savepoints to Dynamics NAV programming. You could explicitly make it commit through the use of savepoints, and then explicitly rollback to the last successful savepoint. To do this NAV has to include savepoints after each line of code and then keep track which savepoint should use if transaction get failed.
By doing this and adding implicit transaction to NAV will break the simple and yet very advance foundation.
If Microsoft really do that then I will lose one thing that I really love about in C/AL programming, that is Handling transactions by its own. Therefore lets get satisfied with what we have right now and lets not ask for error handling in C/AL programming.
Once again thank you VJEKO for your lovely article and if any of you need more info please refer his blog post.
Thank you and Regards,
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?