Ken, Just a WAG but check you have TableValidate set to as VFP may well be trying to test the integrity of the table each time you open it and to do this it needs exclusive access.
0: Do not perform table validation. 1: Validate record count when opening a table. 2: Validate record count when appending or inserting records and writing them to disk. 3: Check .dbf header before saving append operation to disk and modifying header.
Default setting is 3 from VFP 8 onwards.
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Ken Dibble Sent: 08 January 2016 15:37 To: profox@leafe.com Subject: Error 1569
Hi folks,
I realize that at this stage of my career I should really understand the simple stuff. Apparently there's something I don't understand though.
For this scenario, please humor me by assuming that all of the following is true (some of it is verified by my error logging system, but the system does not explicitly test each of these assertions):
I have a bunch of VFP tables on a Linux file server. In the same location is a .dbc file for these tables that is not corrupted. The connection between the workstation and the server is working. I do not use private data sessions; all environmental settings are therefore global. SET MULTILOCKS is ON SET EXCLUSIVE is OFF This is a multi-user application. The database was explicitly opened: OPEN DATABASE [path\dbc file] SHARED Many things were done.
Much later, we ensured that all users but this one were logged out, and created a semaphore file on the server that will prevent any users from logging back in. We are now in a single-user situation. So we issue:
CLOSE TABLES ALL CLOSE DATABASES ALL
The database is definitely closed at this point. However, issuing a correctly-formatted USE command on a table in that database is supposed to explicitly open the database again.
Next, the code issues:
IF NOT USED [appropriate alias, of which there can be only one for this table] USE [full correct path\some.dbf] IN 0 ENDIF
The USE line sometimes, but not very often, generates Error 1569 ("Database [path\dbc file name]: File access denied").
According to MSDN, I have "attempted to write to a write-protected database container (.dbc) file."
Again, assuming everything I've told you is true, what could be causing this?
Thanks.
Ken Dibble www.stic-cil.org
[excessive quoting removed by server]