Record locking

[John Esak]

> 	I have *always* done a "write" and then a "close" in a situation
> like this, where I'm working with a control file.  If I didn't do it this
> way, I can show you instances of this type of code not working correctly
> dating all the way back to filePro version 0.95 on Tandy Model 16's.
>

I wasn't going to comment on this thread because I had heard it in the FP
Room and didn't know what to offer toward solving it... but since both of
you have shown this code...


    write filename;  close filename

and say it is a good (and even necessary) syntax... it just has to be said.
This is patently, and completely _wrong_. Mike, Richard... it has been said
over and over and over again in this forum and elsewhere. The CLOSE
statement _does_ a WRITE as part of what it does. There is simply NO need to
do a WRITE before a close. It is just redundant, not needed, inelegant...
whatever you want to call it... but please, please don't call it required.
Mike, you say you can post code that will show a write that does not work
properly... please do. I don't believe a properly written code segment
incrementing a control file field and then writing the record to unlock will
break.  At least, I will say this with absolute confidence on the *nix
platforms. If you are saying Windows is different... well then you can't be
talking about a .95 version...  Put up the code you mentioned and show us
how it breaks. I would very much like to see a specific example... I'm sure
FP Tech would, too. Heck you might have exactly the code which discloses
whatever Richard's problem is.

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