ArcherPoint Dynamics NAV Developer Digest - vol 201
The NAV community, including the ArcherPoint technical staff, is made up of developers, project managers, and consultants who are constantly communicating, with the common goal of sharing helpful information with one another to help customers be more successful.
As they run into issues and questions, find the answers, and make new discoveries, they post them on blogs, forums, social media…so everyone can benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this community—so we thought, wouldn’t it be great to share this great information with everyone who might not have the time to check out the multitude of resources out there? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from NAV experts and devotees around the world. We hope these insights will benefit you, too.
ERROR Code in Microsoft Dynamics NAV: A Discussion
Bill W asks, “I’ve found that if I call ERROR(”) like this it will not actually throw an error message but it will roll everything the user has done back to the “original” state. I’m thinking about using this in the case where they cancel a confirmation dialog and I want everything back the way it was before they chose to cancel. This feels hacky and I can’t find anything documented about using ERROR like this. Is this a bad idea?”
Chris M replies, “No, it is a good idea, one less ‘click’ after the user already states they want to cancel. If for some reason it’s not obvious that the user is going back to the beginning (such as if the confirmation is weirdly in the middle of something), then you might want the error statement to inform them of such. But, in general, I think it’s a good idea.”
Kyle notes, “I’ve used it like this for years.”
Senthil shares, “If the user has not confirmed the dialogue, then the system ‘exits’ and rollbacks the changes. See below example in Codeunit 80:
InsertTempSKU(“Location Code”,”No.”,”Variant Code”);
IF NOT CONFIRM(
Text062Qst,FALSE,FIELDCAPTION(“No.”),Item.”No.”,FIELDCAPTION(“Location Code”),
“Location Code”,FIELDCAPTION(“Variant Code”),”Variant Code”)
THEN
ERROR(”);
My question is what is the difference between Exit and Error(”)?”
Kyle responds,
SalesHeader.”Posting Date” := TODAY;
SalesHeader.MODIFY(TRUE);
EXIT;
SalesHeader.”Posting Date” := TODAY;
SalesHeader.MODIFY(TRUE);
ERROR(”);
The first example actually updates the sales header, but the second does not. The ERROR causes a rollback of the whole transaction back to the previous commit.
Matt T explains, “In Senthil’s example, I’m not sure there is a difference, unless you want to make sure you stop execution. It can’t cause a rollback because there is nothing to roll back. You couldn’t have that Confirm statement in the middle of a transaction if there was. That’s if you just look at that code block on its own.
To make it more confusing that code is at the end of a local function in CU80. So it does seem like an EXIT could be appropriate. But the function is called from another function in CU80 and there are lines of code that could execute if an error wasn’t thrown. I don’t use ERROR(”) often, so if I’m mistaken in any of this then by all means correct me.”
Jon adds, “I’ve used Error(”) quite a few times in the past. I don’t think it’s a hack. I like to use it for testing purposes as well.”
Denise exclaims, “I’ve seen this, but never knew what it did. Thanks for the info!! It’s a great idea!!”
Bill furthers the discussion, “Senthil’s example is called in a function on line 559 of CU 80 (2016). Also, this is the first time I’ve used the “Go to line” feature….
Some examples found in CU 80, 90, 1100, 229, 10145, PAG1808. The general pattern is that this is called after a CONFIRM has been declined and an additional error message would be superfluous.
My first code search turned up nothing because I just did ERROR(”) which gave me every ERROR instance and every ”. Searching for “ERROR(”)” turns up all the right stuff.”
If you are interested in NAV development, be sure to see our collection of NAV Development Blogs.
Read the “How To” blogs from ArcherPoint for practical advice on using Microsoft Dynamics NAV, and contact ArcherPoint if you need assistance with Dynamics NAV.