return value of on delete trigger
girish.joshi
Member Posts: 407
I have a question about the return value of the ondelete trigger.
the docmentation says that you can check the return value of ondelete to catch errors from the trigger, like so:
if rec.delete(true) then
etc...
but when I conducted this test:
if rec.delete(true) then
message('error handled') ;
and in the ondelete trigger of rec
error('error raised')
the message that popped up was Error Raised. The test suggest that the return value doesn't let you know if there was an error. If that's the case, what's the return value for? I am just missing something?
the docmentation says that you can check the return value of ondelete to catch errors from the trigger, like so:
if rec.delete(true) then
etc...
but when I conducted this test:
if rec.delete(true) then
message('error handled') ;
and in the ondelete trigger of rec
error('error raised')
the message that popped up was Error Raised. The test suggest that the return value doesn't let you know if there was an error. If that's the case, what's the return value for? I am just missing something?
0
Comments
-
What were you trying to prove? If DELETE returns true, then the deletion was successful, if it returns false then it was not successful, and the record will still be in the database.
The parameter of the DELETE method is to control whether Navision executes the code in the table's OnDelete trigger.
Try this:
In your table's OnDelete trigger, write this line of codeIF CONFIRM('Do you want to error out?') THEN ERROR('');
Then, change your code to this:IF Rec.DELETE(TRUE) THEN MESSAGE('Everything went well') ELSE MESSAGE('error was raised');
When ou run that code in the debugger, you should see it jump into the table's OnDelete trigger and execute the CONFIRM message. You can then click yes, and you will see that you get the "Error was raised" message, because it would not let you delete the record. If you click No, then it will delete the record, and you should see the "everything went well" message.0 -
Actually, Denster, according to my tests, you are mistaken.
If after the confirm you say you do want the error, you DO NOT see the 'Error was raised' message. Instead, you simply get an error.
That's my point. The whole point of putting the call inside the if statment is to catch the error. But instead, code execution just stops. I ran into this problem while trying to create a batch routine.
Interestingly, if instead of putting the statment in an if statment like
if rec.delete(true) then ...
first nest the code inside a codeunit's run method, like this
OnRun(Rec) ;
Rec.delete(true)
and then elsewhere.
if codeunit.run then
message('no error') ;
else
message('error raised') ;
We DO see the message.
Am I missing something? Is this the preferred idiom for catching errors in OnDelete? In any case, it seems like something people might want to be aware of.0 -
The delete is not like codeunit.run. The meaning of "if delete then" is that when there is error in delete process of the record, the return value is false (for example when the record is not existing or you have no rights for deleting in the table). It is not connected to "error" function in OnDelete. Same is true for .Insert and .Modify. (for example insert return false if the record already exists in the table...)0
-
No I am right, partially at least
. Where I went wrong is that I put this little bit of code together without testing it myself. It assumes that the error in the OnDelete trigger doesn't show if you put the DELETE statement within an IF statement, which is not true. I've been working with codeunit return values a lot lately, and that structure is in my working memory somehow. If I had tested this code I'd have caught it. Thanks for pointing that out to me.
The error runs regardless, and will show regardless, and will terminate a transaction regardless. It has nothing to do with whether the DELETE itself fails or not. It's not the DELETE that fails in my example, it's just another error inside the code of the OnDelete trigger.
I put some more code in a form and tested it this time. First just remove the code from the OnDelete trigger, that won't work in this example. For this test I created a new table with a Code field called 'MyCode'. I also created a blank form with one button and put a record variable called MyRec that references the new table. Here's the button's OnPush code, with some explanation:MyRec.INIT; // creates a new blank record MyRec.MyCode := 'HGHG'; // sets the MyCode field to a value that I know doesn't exist // running DELETE will fail, because there is no record with that value IF MyRec.DELETE THEN BEGIN MESSAGE('Everything went well'); END ELSE BEGIN MESSAGE('error was raised'); END;Now when you run this code you should see the 'Error was raised' message.
The return value simply tells you whether the DELETE method succeeded or not. Any error that is raised inside the will be raised regardless. If you want those not to show up you can use it by running a codeunit inside an IF statement, that surpresses the error message.0 -
Yes, this is exactly what I tried to describe... :-)0
-
Glad I could help clear this up.0
-
the point is that in OnDelete trigger you can either raise ERROR or silently ignore the user deletion request. In the latter case you use the return value to inform the programmer that called your trigger that deletion operation did not go well. So the return value is usefull in cases where you do not raise deletion errors but silently skip deletion request.
In practice it would look like user presses F4 but the record is not deleted. And indeed it looks confusing - any examples of such behavior in navision standard objects ?0 -
Well that is another story. the boolean parameter in the DELETE method determines whether or not you want the OnDelete trigger to run, not whether a user request is 'silently handled'. You can write 25 pages of code in the OnDelete trigger, but if you do DELETE(FALSE), none of it will execute.
When a user presses F4, they will always get a confirmation message. I don't see what is confusing about that.0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.7K Microsoft Dynamics NAV
- 18.8K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 328 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions

