Record locking

[John Esak]

> > John is still not used to thinking in terms of "Windows", although
> > PFSYNC and the other things we have discussed do help the Windows
> > caching problems (but don't necessarily cure them).  I don't recall
> > seeing these problems occur on any of the Unix systems I've worked
> > with.

I have been using Windows (and solely Windows) for my access to _anything_
including my Unix boxes for 10 years... since 3.1. The Unix boxes have _no_
consoles or other access except from Windows. I would say that I know just
about every keystroke there is in the GUI... and I understand the registry
architecture, the virtual memory stuff, and some other few things about the
filesystem types. I am conversant with 98 and 2000 Professional. I've
installed hundreds of 95/98 systems 40 or 50 2000 Pro systems and XP Home
and Professional probably 10 times a piece also. So, I wouldn't say I'm not
used to "thinking in Windows". I am no expert by any stretch, but I think I
do know far more than the average bear about these systems. However, I do
plead not knowing much about how filePro works on them.  And yet I'm
certainly capable of learning.  The above statement, for example, is pretty
much wrong... or inaccurate at the least. All that PFSYNC does (on Windows
that is...) is force the immediate writing of the directory table. In other
words, from long ago DOS days... (and I've probably installed hundreds of
DOS boxes from scratch, too) :-) Anyway, it is such and always has been such
that the directory entry for a file does not get updated until you leave the
filePro processing table... So, a situation can occur which might leave
things incorrectly mismatched. For example, you are running a process which
adds free records to a file... increasing its size... the machine crashes
before the end of the filePro table... the directory entry still has the old
size of the file.  Hence, PFSYNC... that is it's purpose.  To say it helps
with the "Windows caching problems" is only minimally true and even then
only if your stretching its meaning a bit.

Therefore, say in Richard's case, I do not think it is helping in the
WRITE/NOT-UNLOCKING-THE-RECORD problem.

As for timing and speed... no, I still disagree with those who say this will
affect how filePro works.  The faster your system, the faster filePro will
work, that's all. True, Brian mentioned Xenix not working on newer, faster
hardware, but that is not even a close analogy. It's just too different a
situation.

As for faster computers messing things up... this is not even a starter for
m. It is pretty simple logic. Things happen in a specified sequential order
inside these beasts, and speeding them up isn't going to change that
sequence. It isn't going to move a lock/unlock sequence around in such a way
as to make it fail. If that were to happen, then one hell of a lot of other
things would be going wrong as well.

I would keep looking toward the improperly setup network first. As for a new
protocol or error or change in the new 2003 server... well, perhaps, but I
think if that were the case (and Ken agrees) many, many more programs and
people would be affected and complaining. Assuming Richard's problem is
repeatable as I think it is... only on 2003 Server... he will have a tough
road to hoe getting that fixed... or even proving it to anybody... without
perhaps arranging a login to the system and an actual demonstration ready to
go for the debugging version of clerk... I hope he can arrange this...
otherwise this may remain a mystery.

JE