VFP8 SP1 Error 108 "File is in use by another user"

[giannit]

Hi Everybody!

The following problem does not show in VFP7 SP1 neither with the old Foxpro for Windows 2.6a.

At the moment I can't test it in VFP8 WITHOUT SP1. I must reinstall it.

Everything happens under Windows XP Professional eventually connected to a network.

These are the few and easy steps to verify the malfunction:

1) Open SHARED a table located in a network folder and apply FLOCK().

2) Now from another workstation on the network or on the same machine but launching another copy of VFP8 try to open the same table also in SHARED.

Well, to me and to my clients VFP gives:

Error 108 "File is in use by another user"

If you don't apply FLOCK() you can open it without a hitch and than apply FLOCK() without any strange behavior other than the well known obviuos limitation that you can't write on it until flocked by another.

Is there a new setting in VFP8 I can't figure out?

Thanks for the attention. (And sorry for my English... )
Gianni Turri

 

[DSummZZZ]

I don't have VFP 8 so I can't test or comment on any different behavior it may have. But.....
In my opinion, you should rethink your locking design. You really should never have to FLOCK() a table in the first place. FLOCK() locks the entire table (i.e. the header record) so it effectively cannot be accessed by another process or instance. The only time the header needs to be locked is for a brief instant while the table is being updated using append or insert a record. Using replace or delete or whatever, which updates a record will momentarily lock the header to change the date, but you only need to issue RLOCK() at that point.
Then again, I don't know the entire scenario you're using either.


-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[pweegar]

Same thing happens in VFP 6. In fact I see it on occassion. Generally, waiting a few seconds and trying again seems to work. I wonder if it could be 1) A slow network, 2) a network glitch 3)Some kind of network time out or 4) A drive mapping going to sleep and not responding in a timely manner.

We use foxpro 6 to develop bar code apps for our document scanning process. The error occurrs at really strange times (including an Administrator running an admin job). Very frustrating.

 

[giannit]

I have found the solution on the ProFox Mailing List <profox@leafe.com>.

Thanks to &quot;Juergen Wondzinski&quot;, &quot;wOOdy&quot;!

wOOdy begin------

Try your code with a SET TABLEVALIDATE TO 0.
With the Default options, VFP8 tries to validate the DBF-Header for corruption.
For that it has to briefely lock the header, which conflicts with your FLOCK().

wOOdy end--------

TABLEVALIDATE has four level of table integrity check

0 - None
1 - Validate record count when opening a table: the table (.dbf) file header is locked during validation
2 - Validate record count when appending or inserting records and writing them to disk
3 - Validate as Level 1 + Level 2

TABLEVALIDATE by default is set to 3

Using

SET TABLEVALIDATE TO 0
or
SET TABLEVALIDATE TO 2

I have solved my problem.

Thanks everyone!
Gianni