"Advanced" COMMIT Management

Belias

hi everyone,
I have a question about COMMIT. Here's a code sample

repeat
  if mycodeunit.run(mytable) then *****
    //retrieve mytable values from mycodeunit
    //do the INSERT/MODIFY of mytable
  else
    //retrieve mytable values from mycodeunit    
    //add a log
    //do the INSERT/MODIFY of mytable
  COMMIT;
until something = true;

now, the real catch is in "mycodeunit"

NoSeriesMgt.InitSeries("this is the standard NAV function");
//the function initseries will make the entry number on MYTABLE and modify the number series line table
//populate some fields in MYTABLE variable
ERROR('something goes wrong, e.g. lock timeout');

now, the error should roll back the transaction till *****, thus the number series line will go back by one, isn't it?
I'm 99% sure of it, but i'd like a second opinion, because the process is critical.
Thanks in advance

jglathe

Hi Belias,

yes, it should roll back the no. Series line.

with best regards

Jens

pdj

(nothing)

jglathe

Hi Belias,

I think CU13 is a good example for this. The Posting Nos. are generated consecutively while the journal lines are posted. And it is rolled back if something bad happens. However, for every No. Series, a different NoSeriesMgt Codeunit is used. So maybe there is a reason for this... some fixing on only one No.Series for one instance of NoSeriesMgt.

with best regards

Jens

Belias

Ok thank you. I've solved the bug (the rollback had reset the no. serie back by one number, but i was still inserting the updated no. serie)
e.g.:
- last no. serie used = AAA010
- make no. serie AAA11
- last no. serie used = AAA011
- ERROR
- rollback (last no. serie returns to AAA010
- get the created entry no. (still AAA011)
- create the entry to AAA011 while the last no. used is AAA010
(then, on the second loop, i found the same key of my entry no., so i modify the existing AAA011 instead of creating a new entry)

phew...it was hard to find (nearly impossible to replicate, process running on NAS, and error was random, depending on the locks).
problem solved with a commit after the

NoSeriesMgt.InitSeries("this is the standard NAV function");

because missing entry numbers in the sequence are acceptable.