Hello,
we hit a problem in our application and i could reproduce it with this small code:
do transaction:
RUN P_REKLA.
pause.
undo.
end.
PROCEDURE P_REKLA:
CREATE ER-REKLA.
ER-REKLA.MANDANT = 8 .
ER-REKLA.NUMMER = etime .
ER-REKLA.KONTONUMMER = 1 .
ER-REKLA.HAGE-KZ = "KZ" .
ER-REKLA.REKLAMATION = -4.
END.
This is the table (index) definition
u er-rekla 400 3 + MANDANT
+ REKLAMATION
+ HAGE-KZ
This is the query in another session, when the first is stopping at pause
for each er-rekla where mandant = 8 and reklamation <= 0 use-index ER-REKLA no-lock:
disp er-rekla.reklamation format "999-".
end.
And this is the output
•••••••••••••
•Reklamation•
•••••••••••••
• 000 •
• 003-•
• 002-•
• 001-•
The first record with 0 is in wrong order.
We used it (old code) like a sequence to get with FIND FIRST the lowest record.
But user in session 1 runs code like this during an active transaction and creates this uncomplete record.
The next user gets the record with 0 with FIND FIRST and tries to create a new record with -1 (old -1) and hits a index error because it already exists.
We are wondering about
- order
- incomplete record, because the other three fields are already correct in the database and visible for other sessions.
Now, we have this in many many lines, is this our fault and we have to review our complete code?
We checked everything, this helps:
- one assign (not sure whether it's o.k. for all fields in real code)
- find current [buffer] exclusive-lock
Stefan