Record locking

[GCC Consulting]

I agree with you about doing nothing in between the "getting" of a unique number
and the incrementing and writing of that field out  as in:

   them" lookup ctrl=cotrol_file r=("1") -p
   then: num=ctrl(1);  ctrl(1)=ctrl(1)+"1";  write ctrl

This is all the code that is needed... end of story. It works. It has always
worked for me... and simply never failed. Again, I stipulate that this is on
Unix and Xenix systems of the past 20 years. I can not vouch for the Windows
product.

One other minor point. Richard's code that goes out to check if the number has
been used before... well, that makes _no_ sense to me. Why would you have to
check such a thing? If you are only supplying the next highest number out of a
control file in the way shown above... there is no need to check whether the
number you've just retrieved has ever been used... how could it be?

As for the way you are incrementing the number itself Richard, it is a little
roundabout. You are adding the number you just assigned to the number instead of
adding "1" to the number itself. No big deal, but it is a little odd and if that
assignment is not specifically "written" maybe that is where the problem is...
_although_ the way filePro works this should absolutely NOT be a problem. It is
just odd that you do it this way.

Just so no one gets the wrong idea. I believe Richard is having the problem he
describes... I also believe whatever he did to fix it appears to have fixed
it... but it is simply _not_ an endemic filePro problem. How, could it be? It is
the basis upon which nearly _every_ filePro program has ever been written... at
least in my experience... and that is with lots of programmers, lots of
programs, lots of years... etc., etc. The times I've ever seen a duplicated
unique number, more than likely there has been a power failure, a bad spot on a
hard drive... any other thing but the fact that filePro (or the O/S) could just
decide to do it wrong one time as opposed to another.

John

--------------------------------------------------------------------------------
------------------
A couple of points,

1. I do think this was other then a filePro problem.

2. I have some unique requirements at this client's site and that is to allow
them to enter an order # instead of using the "next available order #".  Not the
best of situations, however they are paying the bills and I have to accommodate
their requirements.  This makes it necessary for me to check the value.  In most
cases, a manually entered order # will be below 1000.  It will be entered,
processed and then deleted.  These are orders that they don't want in their
sales history, but do appear in their accounting.

3. I also have to implement an order number control file which holds any
"cancelled" order #'s. i.e. the order started and the stopped for one reason or
another.  At the present time, the clerk can restart the order, enter the order
# again, and if not used by someone else, continue with it.

John, you are correct in that I don't need write and close one the same line.
However, I was testing the program and kept adding commands until my problem
disappeared.  I should have changed the write to close and left the sync in
place.

As drives and computers get faster, timing problems are bound to happen
especially with windows based systems. 

Richard Kreiss
GCC Consulting