DOES TESTFIELD in a NAV2016 event trigger prevent VALIDATE?

rsaritzky

Hi all,

In the codeunit that releases a Transfer document, it does the following:

VALIDATE(Status,Status::Released)

We have an addon (Chargelogic Shipping) that has added some event trigger code in the OnAfterValidate event. It does, among other things, a TESTFIELD command. We've observed if this TESTFIELD fails (generating a message), that the Status field still changes.

So, my question is: Can anyone confirm that an error generated in an OnAfterValidate event does NOT cause the VALIDATE to fail? It would seem reasonable that this is the case, but I'd sure like to know.

Thanks

Ron

Kishorm

That would seem correct, I would expect an error in the OnValidate event to rollback any changes done in the OnValidate trigger but not if the error occurs in the OnAfterValidate event as you have described.

EDIT: The above is incorrect, please see later post below...

rsaritzky

So far, in observing what happens, this is true (OnAfterValidate event errors do NOT cause the VALIDATE to roll back). But I asked Mark Brummel, and he said that both the VALIDATE and OnAfterValidate events are within the same transaction, so it SHOULD roll back.

Hmmmmmm.....

Kishorm

Oops, just read this again and realised I misread / misunderstood the original question. When you said the OnAfterValidate event, I thought you were referring to the OnAfterValidate trigger on a page and this is why I said I would not expect it to rollback changes.

I now understand that You are actually talking about events like OnBeforeValidate and OnAfterValidate - and I totally agree with you and Mark - any changes in these 2 events would be in the same transaction as changes to the original OnValidate trigger and so an error in any of these should cause changes to rollback.

This does seem like a bug so I would test in the latest build and if it's still a problem then report to Microsoft. Apologies for the initial confusion.

mohana_cse06

I tested it and rolled back with TESTFIELD also.
which CU are you using?
or can you show event code?

Kishorm

When you say...

We have an addon (Chargelogic Shipping) that has added some event trigger code in the OnAfterValidate event. It does, among other things, a TESTFIELD command.

...in the "other things" it does, it doesn't by any chance do a COMMIT does it? That would certainly explain what's happening.

David_Singleton

This is not a new issue, there have been some earlier versions of Navision where there seemed to be some inherent COMMIT happening before some triggers. For example insome Nav 4 builds there was a bug where INSERT(TRUE) where the record existed, would give and error and fail to insert the record, but code upto that point could be commited, changing the code to

If not INSERT(TRUE) then
ERROR('....

would function as expected.

Try to chang ethe code to

IF MYFIELD <> "Value" THEN
ERROR("...;

This will let you know if its a Nav bug, or if there is something wrong in your code.

rsaritzky

Thanks everyone for the comments - Yes, this is EVENT code being called by the OnAfterValidate Event. I did a test with simple code, and TESTFIELDs that fail in the event do in fact roll back.

In the Addon's event trigger, there is a COMMIT before the TESTFIELD - we are still trying to determine if this results in the out-of-sync condition that we are observing, but it does appear that the COMMIT overrides the update transaction's integrity from "end-to-end".

Ron

Kishorm

As I said above, a COMMIT would cause exactly the scenario you are describing so it's all working "correctly" from a NAV point of view.

The question is should there really be a COMMIT in the OnAfterValidate event?.... I'd say this is not a great idea as it would cause problems as you have discovered.

rsaritzky

I agree with you - I don't like seeing COMMIT's in this event code. But that is in our Addon provider's code - we are in the process of testing it and encountering errors, and we are trying to get in contact with the right resource at the Addon provider to explain what their code is trying to do - it's a new Addon that we aren't completely familiar with yet, so we are awaiting assistance from them. However, our system is heavily customized by in-house developers (including me), so I'm trying to determine if any of our custom code is affecting their stuff. Our code has not been moved to event codeunits yet - it's still inline in the tables and related codeunits - so it's possible that something that we added is affecting their functionality. I'm just doing my best to help assure that our code and theirs works together. So I'm just trying to get confirmation that a COMMIT in an OnAfterValidate event will "override" the transactional integrity. This stuff is so new, that only a handful of people in the world know the answer to this question.

Ron

Kishorm

Whether the COMMIT is in the actual OnValidate trigger itself OR in a separate function/codeunit called from the OnValidate triggger OR in the OnAfterValidate event is irrelevant - you get the same result. This is not an issue related to events.

To be clear COMMIT will not "override transactional integrity" - if you are using the CONSISTENT command to enforce transactional integrity and a COMMIT is encountered (even in an event) the transaction will fail if the database is not in a consistent state.

You need to explain the situation to the addon provider demonstrating how it is causing a problem and get them to remove the COMMIT from their subscribed event. At the end of the day their code is causing bug (status being changed even though an error occurs) so it's up to them to fix it.