Hello,
I'm looking for opinions on a 'somewhat creative' construct.
The following works:
DEFINE VARIABLE i AS INTEGER INIT 1 NO-UNDO.
processing:
DO TRANSACTION
ON ERROR UNDO processing, LEAVE processing
ON STOP UNDO processing, LEAVE processing:
FOR EACH sometable NO-LOCK WHERE sometable.id = 1:
IF somecondition THEN DO:
BUFFER sometable:FIND-CURRENT(EXCLUSIVE-LOCK).
DELETE sometable.
END.
ELSE
DISPLAY sometable.
END. /* for each sometable */
END. /* processing */
Great way of doing this conditional update, and the buffer is automatically released also; it should be in the manual.
There's a reason for the language not allowing you to upgrade the current lock status of a FOR EACH buffer, so the safe thing to do would be to use a different buffer and delete the record that way. I'd expect to see a bit of a performance increase in that the engine doesn't have to do the dynamic lookup / call thing in order to change the current record status for every record it deletes.
I was just wondering if the reason it's not allowed is because they don't want to allow you interupting the query or if it's actually not 'allowed' to upgrade the lock status. After all you also upgrade the lock status if you have a SHARE-LOCK and decide to make it an EXCLUSIVE-LOCK in the middle of a for-each.
I recall there was a reason, but I can't remember what it was. You'll need to do some digging in the KB or contact PSC TS to get a definitive answer.
Hello,
I contacted tech support and they asked development. The answer is even better than I had hoped for:
The fact that FIND CURRENT does not compile is a bug as it will never point to another record. It is now logged as bug# OE00207951. The workaround for the bug is to use the dynamic construct provided above.
Regards,
Jan
Cool!