CODEUNIT.RUN – Conclusion

Contrary to the other run-able CSIDE objects – i.e. Page, Report and XMLport – we can run a Codeunit and catch the result from this execution: TRUE or FALSE

Syntax:

[Ok :=] Codeunit.RUN(Number[, Record])

So if we call CODEUNIT.RUN and request a return value, as illustrated by the two first examples in this series – CODEUNIT.RUN #1 and CODEUNIT.RUN #2 -, this means that basically any runtime error emerging in the execution of the codeunit (as defined by the Number) will be caught by the system and will result in CODEUNIT.RUN to return FALSE.

Unfortunately there seems to be one exception to the rule – there the basically above – and this is illustrated by my third example, CODEUNIT.RUN #3, even though this example does not really deviate from my second example. The only difference being the table the double insert is operated on. CODEUNIT.RUN #2 operates on the Customer table and CODEUNIT.RUN #3 on the Shipment Method table.

Having in mind to write this short series on CODEUNIT.RUN I stumbled across this post of Bodo addressing this one anomaly – so these credits go to him. In short (as you might not be able to read German):

You will not be able to catch the execution result of a codeunit that makes a duplicate insert of a record as the system will already have thrown the error instead of passing a FALSE to my “catcher” statement.

The deviation that CODEUNIT.RUN #3 illustrates, seems to apply to all tables except for the Customer table. So only in case of the Customer table, it works like intended – did try it on quite some tables, but surely not all. With all other tables your catcher code will NOT get a FALSE passed. And this is clearly a bug as eYe also found out.

This anomaly has been reported to MS and if you feel like voting for it go here.

One Comment

  1. Hi Peter, thanx for adding this info. Probably it's due to my level of understanding, but why does this make a difference regarding the "cathcher" statement on CODEUNIT.RUN? Buffered or not the duplicate INSERT will raise an error. Is is that the  execution of the implicit (I guess not explicit like you state) COMMIT disables any returning of TRUE and/or FALSE?

Leave a Reply

Your email address will not be published.