Record locking

[Mike Schwartz-PC Support & Services]

> and I want it clear
> that even though you said you could "show some code" that breaks... you
> are not going to at this time.  It just keeps things clear. Okay?

	Yes, that's correct, John.  There's just a little miscommunication
about the word "show".  I don't recall stating that I was going to post any
code to the list, nor send any code to fPtech, and I am *not* complaining
about this problem, because I can work around it.

	However, if you ever get to the Green Bay, Wisconsin area, I would
be very willing to SHOW you the problems that I ran into on some of the 900
Mhz Windows '98 machines where "writes" were not releasing the record in
time to avoid conflicts.  Again, I believe it is an IDE controller caching
issue, or perhaps a Windows bug that might very well be resolved in Windows
versions other than Windows '98, or on newer hardware.   And I did believe I
used the word SHOW, and not "post code", since I, myself, can't necessarily
duplicate the problems at some of my other filePro Windows customers.  

	All I was getting at is that it wouldn't do me any good to send you
Windows code or code from filePro 2.0 or 4.1 and have you run it on your
Unix box, only to have you pronounce that "I can't duplicate your error on
my SCO 5.0.7 box running filePro 5.0.13".    

	I do have other Windows specific errors that I have learned to work
around that I would much sooner see fixed.

	For example, when I run a batch of reports, such as an accounts
payable posting batch, using a menu script in filePro 4.8 or 5.0, the 2nd
and subsequent reports will lock up with weird errors that indicate that
Windows can't open some of the filePro files.  I believe that this is due to
hard drive caching problems on the faster IDE hard drive controllers, where
the files aren't written to the hard drive properly before my 2nd report
begins.  I have learned that I have to "space apart" my *report commands in
the scripts with some other program, such as rebuilding an index on an
entirely unrelated filePro file.  If I do that between each *report line,
then the reports will all run correctly.  PFSYNC also helps on network
systems.

	This is another example of something that was discussed a couple or
times on the list a few years ago, and we came up with a work-around.  I
don't know if it is fixed on filePro 5.0.13, but I suppose I could test that
again, too.

	But, I can't reproduce this problem on all Windows machines, either.
When we run into hardware problems like this, it's just not practical to
package up the specific server involved and send it to fPtech for a couple
of weeks to see whether or not they can resolve the problem.

Thanks,

Mike Schwartz