0 pts.
 Record locking (or lack of it)
Bare with me a minute before you throw rocks, but is there a difference in record locking between a Chain and Read? Here's what I'm looking at. We have a control file that contains the next note number. In all our applications we either chain or setll/read the control file, get the number, add one to it, and then update the file. Sounds simple and straight forward, but somewhere along the line note are being created with duplicate note numbers. And the only difference I see is some chain to the file and some setll/read.

Software/Hardware used:
ASKED: May 3, 2006  2:22 PM
UPDATED: May 3, 2006  4:05 PM
  Help
 Approved Answer - Chosen by TomLiotta

You know how you can look at something many times and just not see what right in front of you. Well I think I found the problem, some of the programs where getting the number (say 100), using that number, then adding one to it (101) and updating the file. Other programs are getting the number (100), adding one to it (101), using that number, then updating the file. So you could get two users with the number 101. Thanks for your inputs.:)

ANSWERED:  May 3, 2006  4:05 PM (GMT)  by TomLiotta

 
Other Answers:

all such problems have underlying causes in areas where we are not looking. I am sure the record locking is working. The most obvious possible problem is the a) not found condition for the chain, or b) the not eof condition for the read, or c) the misplaced Set Lower Limit. Is there only one record in the control file? if not, the read might be getting the wrong record. Is this the case?

I do not think it is a locking problem.

Last Wiki Answer Submitted:  May 3, 2006  3:23 pm  by  DaddyCOZ   0 pts.
Latest Answer Wiki Contributors:  DaddyCOZ   0 pts.
To see other answers submitted to the Answer Wiki: View Answer History.


Discuss This Question:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


 

all such problems have underlying causes in areas where we are not looking. I am sure the record locking is working. The most obvious possible problem is the a) not found condition for the chain, or b) the not eof condition for the read, or c) the misplaced Set Lower Limit. Is there only one record in the control file? if not, the read might be getting the wrong record. Is this the case?

I do not think it is a locking problem.

 0 pts.

 

As soon as you get the number for the next note, you should immediately update it. This way the next person who requests the next note number will really get the next note number

 25 pts.