Detect if any COMMIT has occured

John_Reinhold

Running NAV 6.0 on SQL 2008

I have a codeunit that calls many codeunits throughout the application.

In my code I need to know if any COMMIT has occured, example:

CODEUNIT.RUN(C1);
CODEUNIT.RUN(C2);
CODEUNIT.RUN(C3);
CODEUNIT.RUN(C4);
if ??? then !

In the different codeunits a COMMIT just might be executed. I need to know before continuing my code at the end (???).

A flag of some sort together with the COMMIT statements within the codeunits is not the answer. I have no way to know wich objects/functions in the application that are executed.

How do I go about this?

matttrax

I'm pretty sure you don't, but maybe others can back me up on this one.

I've never seen a global variable that will tell you if you've made a COMMIT or the version of the database you've retrieved (what's that fancy word from the development class, Optimistic Concurrency?) is no longer the most current version.

The way you have your code structured those codeunits will run and afterwards you are looking for a global variable with a value or perhaps a field from a table that will tell you if a COMMIT has been done. That would have to be filled in at the COMMIT statement.

Why do you need to know if a COMMIT has happened anyway? Are you trying to rollback changes or something when an error occurs later?

John_Reinhold

Thanx for the reply, matttrax.

I'm trying to ensure that a bunch of automatically created sale documents can be posted, before it is done. I'm doing this my making conditionary C80.runs and trapping the errors. Inside C80, the COMMITs are not executed, when I'm testing. But C80 calls many other codeunits, that might execute commit. After the test, the user needs to know if any or none of them are committed.

Before the looping of C80, I've altered R202 (test report) to save all errors in all sale documents instead of printing them in order to catch most of the errors. The errors are saved in a temp record in i single instance codeunit because this is not cleared upon runtime-errors.

I have no desire to go through every piece of code to eliminate commits when testing.

I've found out that I can insert a record from C/AL before the loop of C80 and then try to read it using ADO-calls (reading committed data) directly to the SQL-server when to loop is gone or when a error is catched. But in order to do this, I need setup of the database user credentials to be saved in a table. And I do not wanna do this, although I can encrypt it.

Jut

One way to handle that problem could be to create a new codeunit (let's call it caller) that calls the other codeunits in onrun-trigger. subsequent to the 4 codeunit-calls, you could add a statement like OK := AnotherCodeunit.RUN. This will fail if no COMMIT was made since the last write-transaction. If you now call the Codeunit caller like:

IF CODEUNIT.RUN(Caller#,Record) THEN
  // Commit was made
ELSE
  // Error occured, use e.g. getLastErrorText to find out if the missing commit was the reason, rerun the Codeunits  now without using Caller-Codeunit

I do not really like that approach but it might still be worth a thought. The most obvious flaw is that it will only tell you if the last write-transaction was commited.

Regards,
Jut

pdj

John Reinhold wrote:

I have no desire to go through every piece of code to eliminate commits when testing.

I'll suggest turning it around, and simply prevent any COMMITs. This can be done by marking a table as not being consistent. This is used in the posting routines to keep the balance right, but it is also used in the Mobile solution (codeunit 8703 and 8725) to prevent any commits during request processing.

Then you can be sure they willl call you if it tries to COMMIT 8)

(But you will still need to finish with an ERROR('') to prevent any INSERTs or MODIFYs or DELETEs doesn't get executed when your code is completed...)

John_Reinhold

Hello, pdj

Interesting thought. It just might be a good alternative to my approach. I'll look into the Mobile Sales code and try to figure out how CONSISTENT works.

I'm aware of the error ('') at the end.

But any successions are still welcome...