"Advanced" COMMIT Management

Belias · 2012-03-27

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 · 2012-03-27

Hi Belias,

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

with best regards

Jens

pdj · 2012-03-27

(nothing)

jglathe · 2012-03-27

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 · 2012-03-29

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.

"Advanced" COMMIT Management

Answers

Categories

&quot;Advanced&quot; COMMIT Management

Answers

Categories

"Advanced" COMMIT Management