Messages
Reply
Edit
Delete07:10 pm
3NZ1544VI
| From: | Doug Dodge |
| To: | Harvey Mushman |
I don't think our code EVER had that sort of issue though. *chuckle*
I remember this when I was consulting to SBT... I think we ended up setting a counter inside the loop and if the counter maxed out we would raise an error flag.
ct=0
do while not rlock() and ct<1000000
ct=ct+1
enddo
if ct=1000000
? 'something big fit the fan'
endif
This would prevent the server from completely crashing and let the user know some maintenance was going on.
--hm
Eddie,
One of the old tricks we used to do was this (two lines of code with nothing inside the DO WHILE loop)
DO WHILE NOT RLOCK()
ENDDO
* Do your chores
UNLOCK
The DO WHILE loop would 'spin' until it could gain access if there was a contention. Also would work for FLOCK as well. It's 'old school' for sure and goes back to FoxBase 1.0 and dBASE III & III+ before that but it did help.
Here's somethig that may also shed a little light: http://fox.wikis.com/wc.dll?Wiki~HeaderLocking
Best,
Doug
Thanks Rick,
Set reprocess is set to 2 seconds. The problem only seems to occur on 1 table so I figure it has to do with something I am doing with that table. The only commands I use on that table that are not using the wwbusiness class are
locate for
scan for
count for
rlock
delete (on the current record - not a scope)
replace (on the current record - not a scope)
I do not think any of those would elevate to a file lock. So I am sort of dumbfounded with the problem. Because it only happens about 1-2 a week it is hard to reproduce.
You should check your SET REPROCESS TO setting. This determines how long VFP waits for a lock. If this is to small, locks fail and you can get frequent lock errors on busy sites.
I have mine at:
SETREPROCESSTO 2 Seconds
and that seems to be OK even for busy sites but it depends and what your locks actually look like for the rest of the app. If some operations elevate to file locks there might be additional problems.
+++ Rick ---
We are using westwind 5.63. We are using foxpro version 9 sp2 tables.
Occasionally, we get the error, File in use by another.
This is coming from line 24 of wwbusiness::save()
The line of code reads: Append Blank
I have been looking at various fixes. My first thought was to put it inside a 'try..catch' and repeat then wait a second and repeat the command.
But then I found the post below and thought it might be a more elegant solution just to turn the tablevalidate off right before the command and then back on again afterwards.
Please let me know what would be best.
Thanks for your wonderful product,
Eddie
Thanks to"Juergen Wondzinski", "wOOdy"! wOOdy begin------Try your code with a SETTABLEVALIDATETO 0.With the Default options, VFP8 tries tovalidate the DBF-Headerfor corruption.For that it has to briefely lock the header, which conflicts with your FLOCK(). wOOdy end--------TABLEVALIDATE has four level oftable integrity check 0 - None 1 - Validate record countwhen opening a table: the table (.dbf) fileheader is locked during validation 2 - Validate record countwhen appending or inserting records and writing them to disk 3 - Validate as Level 1 + Level 2TABLEVALIDATE by default is setto 3
