Topic
8 replies Latest Post - ‏2013-01-25T16:58:04Z by barbara_morris
bogeybetsy
bogeybetsy
43 Posts
ACCEPTED ANSWER

Pinned topic READE and CHAIN Gotchas

‏2013-01-24T10:48:00Z |
We have a file declared in a program as an update file with the following records :

Key Data
4 (any data)
5 (any data)
7 (any data)

And we were looking for the record whose key is 6, and the record whose key is 7 is locked. We found that the following code does not work for and EOF condition:

SetLL ( Key ) File;
DoU %EOF(File);
ReadE(E) ( Key ) File;

ExSr $$FilErr; (this subroutine contains an "If %Error" condition)

If %EOF(File);
Leave;
EndIf;

Delete FileRecordFormat;

EndDo;
What happens is the READE statement tries to acquire the record whose key is 7 (even though we are looking for the record whose key is 6) and since it is locked, a "lock error" occurs - instead of an "end-of-file" occurring! It seems that the READE has to acquire first the record whose key is 7, before it could check if the key of the acquired record is the key being searched.

Instead of an EOF condition occurring, what occurred was an error! It thought that the record being searched existed and was locked when in truth the record being searched was not really in the file BLBDTE. And because of the error that occurred, a rollback consequently occurred.

We have changed the code to:

SetLL ( Key ) File;
If %Equal( File );
DoU %EOF(File);
ReadE(E) ( Key ) File;

ExSr $$FilErr;

If %EOF(File);
Leave;
EndIf;

Delete FileRecordFormat;

EndDo;
EndIf;

Also, the code (for CHAIN as seen) below does not work too for the %Found condition:

C Key chain(E) File
C ExSr $$FILERR (again, this subroutine contains "If %Error" logic...)
c If %Found(File)
c (Do what's necessary here...)
c (Do what's necessary here...)
c EndIf

Like the READE, the CHAIN tries to acquire the record first before checking if it has acquired the record with the right key!

Does the READE (and the CHAIN) really behave this way? Or was the way it was coded really the culprit here?
Updated on 2013-01-25T16:58:04Z at 2013-01-25T16:58:04Z by barbara_morris
  • JonParis
    JonParis
    113 Posts
    ACCEPTED ANSWER

    Re: READE and CHAIN Gotchas

    ‏2013-01-24T14:19:14Z  in response to bogeybetsy
    I've never thought about it before but I am not surprised at the way It is behaving.

    Have you tried using the N extender on the READE to see if that would work? Right now your READE is requesting a lock on an already locked record and hence the problem - without the lock request the READE should work.

    In a simple case such as yours being able to avoid the lock might help but I can't offer any better solutions without knowing what you are trying to do. Do you need to update each record you read? Are you simply trying to navigate to the end of a sequence? If you know the key you are looking for why aren't you just using a CHAIN? You're going to have to read the record anyway for update.
    • bogeybetsy
      bogeybetsy
      43 Posts
      ACCEPTED ANSWER

      Re: READE and CHAIN Gotchas

      ‏2013-01-24T17:13:23Z  in response to JonParis
      The program deletes orphan records. There is a main file where the parent record is read. This parent record is then deleted. So the program searches all such child records from many different (secondary) files. All files are opened under commitment control. Child record/s may or may not exist in the secondary files - if a secondary file has child records, there might be multiple records (one-to-many relationship). If they do exist, a child record might be locked by some other application.

      When I used a CHAIN, the same thing happened...the CHAIN tries to acquire first the record with key = 7 even though record with key = 6 was being CHAINed. And since record with key = 7 was locked, the program flowed into the %Error routine and the "If %Found..." condition was never satisfied. I interchanged the "ExSr $$FilErr" and the "If %Found..." statements putting the "If %Found..." statement first but the "%Found" condition was not satisfied still.
  • barbara_morris
    barbara_morris
    382 Posts
    ACCEPTED ANSWER

    Re: READE and CHAIN Gotchas

    ‏2013-01-24T16:18:43Z  in response to bogeybetsy
    That is expected behaviour for READE. READE is implemented by doing a sequential read and then checking the key.

    But for CHAIN, if you have records 4 5 7, and record 7 is locked, then you should only get a record lock error if you do a CHAIN for record 7. You should not get a record lock error if you do a CHAIN for record 6; instead, you should get an immediate record-not-found. If I were you, I would re-test the CHAIN scenario to put my mind at rest about the behaviour of CHAIN.
    • bogeybetsy
      bogeybetsy
      43 Posts
      ACCEPTED ANSWER

      Re: READE and CHAIN Gotchas

      ‏2013-01-24T17:16:05Z  in response to barbara_morris
      I got the same thing with the CHAIN scenario. But okay, I will re-test the CHAIN scenario and post my findings. :-)
      • bogeybetsy
        bogeybetsy
        43 Posts
        ACCEPTED ANSWER

        Re: READE and CHAIN Gotchas

        ‏2013-01-24T17:27:53Z  in response to bogeybetsy
        Hmm, it is right that the %Found condition is not satisfied. Let me check with a "Not %Found" condition. Sorry about that...
        • bogeybetsy
          bogeybetsy
          43 Posts
          ACCEPTED ANSWER

          Re: READE and CHAIN Gotchas

          ‏2013-01-24T17:36:54Z  in response to bogeybetsy
          I guess my only problem now is why I get a record lock condition for a CHAIN to record 6 when I have records 4, 5 and 7 with record 7 locked by another program...
    • bogeybetsy
      bogeybetsy
      43 Posts
      ACCEPTED ANSWER

      Re: READE and CHAIN Gotchas

      ‏2013-01-25T02:27:52Z  in response to barbara_morris
      I did a re-test. And you are right Barbara! (Again and as usual.)

      Thanks to you and Jon!
      • barbara_morris
        barbara_morris
        382 Posts
        ACCEPTED ANSWER

        Re: READE and CHAIN Gotchas

        ‏2013-01-25T16:58:04Z  in response to bogeybetsy
        Whew! Thanks for re-investigating. And especially thanks for posting your new finding about the behaviour of CHAIN.