append blank in 2.6a causes NOT A DATABASE

[geralyn]

I inherited a client who was having problems with their Accounting system. After a bit of research I found that one of their tables was marked 'Not a database'. I ran HF.EXE (which is a header fixer utility) on it. I was then able to open it. I 'appended blank' and entered some data. I added several records this way. All seemed well. I closed the file and then reopened it only to get the message 'Not A database' once again. I reran HF on it and when I opened it, the new records I had just added were gone. This file is not that large, so it definitely isn't a size issue.

Then I took a different file which had the same structure as the problem file and appended the data to it. I appended all the records from the 'bad' file, then began adding some new records and got the same result (not a database file). Any ideas?

 

[rgbean]

Geralyn,
Just to be clear, there is no "flag" that indicates that it's not a database. When FoxPro tries to open a table, it makes a number of integrity checks, depending on the version, and some of the data in the header. The usual cause for this error, is a comparison of the number of records, as specified in the header, with a calculation of the number of records based on the header size and the length of each record. If they don't match, then you get an error. Other errors can occur based on whether FoxPro thinks there is supposed to be a Memo file (.FPT) or an associated compact index file (.CDX).

Adding a record is at least a two part process - adding the record on the end of the file, and updating the header count. If one happens and the other doesn't, then you have conflict. Note: Because of buffering and block sizes, it may actually take multiple records added to cause anything to be added to the end of the file. Because FoxPro, the workstation OS, and the file server OS (and sometimes even the hardware) all cache the data, I've seen this process cause errors due to systems being shut off ('bad' users or hung systems), systems losing power (no UPS), and bad hardware. In addition, some OSs can be set to delay actually writing to disk (Win98-the original, was actually defaulted this way and so is the Novell Netware client!) W2000 before SP3 also had a caching problem with some non-SCSI controllers.

I'd first review current software updates, and verify Server and network client settings. I'd also check the integrity of the hard disk this file is on - you may simply have the file in a "bad" area.

Rick

 

[tilltek]

On fast machines (any pentium up) I run a data base header check such as DBRX.EXE from my app and it all happens so fast the user sees nothing. I use !DBRX *.DBF and this checks and repairs headers etc for 40-50 data bases files in less than a second.
If, for instance the user is about to enter an invoice, I run DBRX as the invoice app loads.
DBRX.EXE by the way is free ware and is only one of many that do a good job.
Ken F

 

[Grimwaldi]

Try packing and reindexing after running the fixer again. If this doesn't work try deleting the cdx files, then input the index again (remember to write down the index expression before trying this)

Also make sure that it is a 2.6a table and not a VFP table as these are treated differently.

Hope this helps