Record locking

[GCC Consulting]

-----Original Message-----
From: filepro-list-bounces at lists.celestial.com
[mailto:filepro-list-bounces at lists.celestial.com] On Behalf Of Mike Schwartz-PC
Support & Services
Sent: Wednesday, March 31, 2004 2:11 PM
Cc: 'filePro mailing list'
Subject: RE: Record locking

> 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,

If you have this problem, why not run a program against a file with one record,
select it and have the process "sleep" for a few seconds or what ever time you
think necessary?  This way you don't lock a file someone may need.

Richard Kreiss
GCC Consulting