Has anyone experienced "Not a database file" (error 15) errors occuring in situations where there is no apparent cause (like a user crashing their computer)? And then the problem goes away without repairing the table?

If I recall correctly, the "Not a database file" or "Not a table" error occurs when the record count in the table header differs from the number of records in the table, such as if a user or server crashes during an APPEND BLANK. Generally, a repair tool (like FIXFOXRC) has to be used to fix the header before the table can be used again.

In our (FPD 2.5a) application, we have a Novell network with approx. 100 users using our system. We log user activity into a LOG.DBF free table using the INSERT INTO command. The activity log has a large number of records added to it each day. The automatic record locking takes care of contention, retries automatically (SET REPROCESS TO 10), and this has worked well for years.

Recently we have migrated our system to VFP7 and are currently in beta test. Most of our users are running the FPD2.5a version of our system; about 10 users are using the same programs compiled under VFP7. We have made some enhancements (IF _WINDOWS) and this has been working well.

We are wondering, though, if anyone has run into a problem with both FPD/FPW apps and VFP apps using the same free tables concurrently? The strange thing is that when we look in our error log, we see that several users get the same "Not a database file" error over a couple minutes, then the error goes away and folks are able to access the activity log ok. We do notice, though, that a blank record did get added to the activity log.

Thanks for any help or guidance in understanding what might be happending.

John Oliver :)