DBC - "is not a database" error

[Foxtrotter]

Hi guys,

I have a database (DBC) that gives the error that it is not a database. I can however open it with "use filename.dbc" successfully. I have a copy of Recover that I have used successfully to recover and repair DBFs for years. It reports no problems when using it to scan/repair the DBC file.

Any ideas on how to figure out how to fix this?

Thanks

 

[JRB-Bldr]

Since you say:

I can however open it with "use filename.dbc"

What command are you issuing that is generating the error: "Not a Database" ?

Good Luck,
JRB-Bldr

 

[Foxtrotter]

Open database filename

 

[Olaf Doschke]

Is the structure of the DBC ok? Does it have all the fields a normal DBC table has?
CREATE DATABASE newdb and then compare the structure of this and your DBC.

Also, does it have the data a normal DBC has?
The stored procs for example are in one of the first records.

If that structure doesn't work or your DBC is not the same table type (inspect the first byte of your DBC file and compare it to a the first byte of the new DBC).

And what does VALIDATE DATABASE tell? Does it also state "not a database"?

Bye, Olaf.

 

[dbMark]

One difference between a database and a table (I'm sure there are more) is that a database allows longer field names to be used in its tables. I would assume Recover knows not to upset that apple cart but I thought I'd throw that out there just in case.

One common issue causing error 1552 is probably the system shut down or was cut off without closing all the tables and so any tables with added or appended records may not have saved the proper record count into the headers. In that case the header is corrupted but not necessarily the data. I don't know how this applies to DBCs which have a collection of tables but for DBFs VFP detects these inconsistencies ("corruptions") with SET TABLEVALIDATE TO 3 (the default; zero turns off the detection).

I have faq184-7723 that explains it and has code that may be helpful. A DBC contains references to DBFs so I'm not sure what may be needed in that scenario and how to do so.

 

[Olaf Doschke]

Open database does only validate the DBC file, not tables associated with it.

You can surely get that error, if for example the DBC was zapped. Or if a PACK failed on it's way and your DBC file is an empty hull. You have to have a minimum set of records to make a DBC, even if it has no stored procs and table, so even an empty new DBC has a few records in its main DBC file/table.

See this:

Clear All
Close Tables All
Close Databases All

Cd GetEnv("temp")

Local lcDBC, llSafetyOn
lcDBC = Sys(2015)+"database.dbc"
Create Database (lcDBC)
Close Database

Use (lcDBC) Alias thedbc Exclusive 
llSafetyOn = (Set("Safety")=="ON")
Set Safety Off
Zap in theDBC
If llSafetyOn
   Set Safety On
Endif
Use

Open Database (lcDBC) && error 1552

You get the error you report, because the DBC has no rows. So opening a DBC the DBC records are checked for consistency. What's not checked, though, is the existence of any database table. Let me show in another experiment:

Clear All
Close Tables All
Close Databases All

Cd GetEnv("temp")

Local lcDBC, lcDBF
lcDBC = Sys(2015)+"database.dbc"
lcDBF = Sys(2015)+"table.dbf"
Create Database (lcDBC)
Create Table (lcDBF) (iID I)
Use
Close Database
Erase (lcDBF)

Open Database (lcDBC) && no error, though the DBF is missing
Use (JustStem(lcDBF)) && error 1 - file ...dbf does not exist

This shows the DBF integrity nor their field name length nor anything about them plays a role at the step of OPEN DATABASE triggering ERROR 1552.

That you can open the DBC as table shows its table structure is ok, too. But either you fiddled with the DBC records or a file corruption did or a PACK failed in the step to append the old DBC data, or you have a DBC, that's not VFP. Perhaps something from Sybase Advantage Database?

Well, you would know, if it's your own DBC.

If you open the DBC via USE and browse, does it show rows? Or is it totally empty?

Bye, Olaf.

 

[Mike Lewis]

A simple solution might be to restore the DBC from a backup. Even if the actual data had been updated many times since the backup was made, that won't affect the DBC, which only changes when you alter the design of the database in some way.

If you do that, be sure to restore the corresponding versions of the DCX and DCT files as well.

Of course, that doesn't explain what caused the problem in the first place, but at least it will get you back into production.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

What Mike says is true,

viewed from the opposite side it means you best don't do frequent changes to a DBC, like creating and dropping tables or views you generate in some process. For views the best practice is a separate local DBC at a users client, because that also prevents error 1709, when each user has it's own copy of the view definition data. For other tables you only need temporal, either use free tables, cursors or a separate DBC, perhaps even local. Frequent changes to a DBC should be prevented, then you get no corruptions, as the DBC only is read from.

Bye, Olaf.

 

[Foxtrotter]

Hi Guys,

Thanks for all the comments. Here's what I know so far. The DBC does have records verified by the USE DBC statement instead of open database. Using a utility that Westwind had posted sometime back to determine Foxpro versions from an EXE, it is VFP8. The last backup the customer has is from 2014. I tried using the DBC from there but it reports base tables have been changed and does not allow me access to the tables themselves although I can see what they are. The current database has in excess of 218,000 records so it is not an empty shell and interestingly enough, the record counts match between the current and backup. I have not had a chance yet to test Olaf's idea of checking the first byte of the files. I think I will try that as soon as I have the opportunity.

 

[Olaf Doschke]

Foxtrotter,

Thanks for all the comments. Here's what I know so far. The DBC does have records verified by the USE DBC statement instead of open database.

Please, Foxtrotter, compare the data you have in there in the first few rows with the data of a new empty DBC. There has to be a reason this DBC does not validate as being a DBC. Something must be missing here!
That the DBC table isn't empty is a good sign. In my demo ZAPping the DBC table you get the same error, but that of course doesn't mean the error only occurs, when the DBC table was emptied. It must involve the first 5 records.

The current database has in excess of 218,000 records so it is not an empty shell

You misunderstand. The DBC itself does not hold any data, the data always is in DBFs and their accompanying files.
There can be lots of tables and view, lots of fields and lots of indexes, but 218,000 is way too much. Points out there would be much repetition, eg tables repeated for each year, month or even day.
If you have 218,000 records in the DBC, are most of them with deleted flag? It's a sign the application works a lot with table definitions or view definitions and as I said earlier that's a bad move and sooner or later leads to your problem. The main database file is kind of sacred and should only be changed with application updates needing new or altered tables.

The backup from 2014 seems outdated, but as I also showed, the data about tables can be outdated or wrong about its tables, that doesn't render a DBC invalid, there's more to it.

If you can open the DBC with OPEN DATABASE and get no error, it's worth a try to move just the first 5 records (Objecttype="Database") into the old DBC file as it's five first rows to repair it. Obviously better do so on a copy of the DBC. Or vice versa, keep the first five rows of the backup and append the rest of the data about tables, views, etc., then try your newly created DBC.

But 218,000 rows in the DBC? That doesn't sound right.

Bye, Olaf.

 

[Mike Lewis]

The current database has in excess of 218,000 records so it is not an empty shell

I think you are confusing the database with the data tables.

The DBC is the database. Broadly speaking, it contains definitions of the data, not the data itself. It is the tables (that is, the DBF files) that contain the data. Typically, you will have one database and many tables. It is highly unlikely that the database (the DBC) will contain 218,000 records. But one or more of the tables might well.

It would be helpful if you could clarify this point. And also whether it is the database or the tables that were last backed up in 2014.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Foxtrotter]

To clarify, if I use databasename.dbc, the recccount() is 218250 records. This is not any of the DBF files themselves. I actually don't have those tables as they are on the customer site. I only copied over the database (dbc,dct,dcx files). Strangely enough, if I use the select statement eg. select * from databasename.dbc I only get 10,347 records. Grouping it by objecttype:
Database: 5 records
Field: 8839 records
Index: 1278 records
Table: 225 records

I don't understand why the select statement reads a different number of records?

The first several bytes of the DBC is:
30 0F 01 02 8A 54 03 00 28 02 A5 00 00 00 00 00

This compared to an old DBC:
30 0B 05 03 72 77 00 00 28 02 A5 00 00 00 00 00

It seems the first byte matches but the next several do not but the last half matches again.

Thanks.

 

[Mike Lewis]

I don't understand why the select statement reads a different number of records?

That's almost certainly accounted for by deleted records. RECCOUNT() gives you all the records, including those flagged for deletion. The SELECT statement produces a result set without the deleted records.

Even so, 10,347 non-deleted records seems remarkably high for a DBC - although if you've really got a total of 8,839 fields (across all the tables), that might account for it.

Might be a good idea to pack the DBC.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

What Mike said,

And from your byte mark 0x30 (remember, I only wanted to know the first byte, literally, that's the table type), the DBC seems ok.

But everyting aside, the DBC is just the meta data about which tables & views exist in the database and what fields and indexes they have. It only contains that info. If you need to work on the DBC, then load DBC+DBFs, only downloading the DBC should work, as far as OPEN DATBASE goes, but of course you can't open any tables, you don't have them.

How long are you working with VFP, your nick name Foxtrotter gave me the imppression you are a globetrotter in regard to FoxPro.

225 tables is quite a lot, 8839 fields in 225 mean an average of ~40 fields per table, that sounds reasonable. Also there are in average 5-6 indexes per table.

That all is fine, but you don't have "the database", if you only have the DBC file. Even in regard of the DBC you have to have a file triple of DBC,DCT and DCX file. If you only got the DBC it's also no wonder OPEN DATABASE causes an error. So now you give the impression you really just have too little files and that's all there is to it.

Bye, Olaf.

 

[Foxtrotter]

Hi Mike/Olaf,

I do have the file triple of DBC,DCT and DCX and have checked that there are no deleted records. I would agree that the number of records is extremely high. Many of the records are objectid=0 which makes me think these records are invalid. The file size of the dbc itself is around 30MB.

Olaf, unfortunately I am no globetrotter in regard to FoxPro. I have worked with Fox 2.6 in support and development of an old in house system for many years. I have used VFP but not much with the database containers, mostly writing add on features to the existing Fox 2.6 system. We will be transitioning off of Fox 2.6 finally this year. I'm not a consultant but am only trying to help a local business out as a favor since it was determined it was a Fox based system. I originally saw this as a fun challenge that would be easily fixable but quickly ran out of ideas so I enlisted the experts advice here.

If I can get the database to where it seems like it will open properly, I can remote back to the customer's computer and copy it over to give it a try.

 

[JRB-Bldr]

You did not mention whether your problem is exhibited on the Customer's System or just on your own copies of the system files.

I can remote back to the customer's computer and copy it over to give it a try.

Can you remote into the customer's computer and make a Copy of the Database in question?
And, if so, then try to do an OPEN to the Copy and see if it works.

Good Luck,
JRB-Bldr

 

[Foxtrotter]

Sorry jrbbldr

Yes, the customer exhibits the same problem. That's how it got started. I made a local copy on my machine here offsite in order to try to repair the file. So, yes, the files I am currently working with are copies of the original from the customer and have the same issue. I also made a copy of my copy just in case I mess it up I don't have to go back to the customer machine.

 

[ggreen61]

What are the physical file sizes as reported by the OS? Does the any of the files exceed 2G in size? If so, this is the problem.

 

[Foxtrotter]

The physical file sizes is 34MB so it isn't near the 2GB limit nor are any of the other DBF files.

 

[dbMark]

Using faq184-4353 this is the record count listed in the headers of the two DBCs, including deleted records, as found in the 5th - 8th bytes in the header.

Now DBC: (hexadecimal) 8A 54 03 00

138 + (84*256) + (3*256*256) = 218250 records

Old DBC: (hexadecimal) 72 77 00 00

114 + (119*256) = 30,464 records

The record offset (9th & 10th bytes): 28 02

28 + (2*256) + 1? (count from zero) = 540 or 541 bytes
Where records start after the header.

The record length (11th & 12th bytes): A5 00 = 165

Based on the above, the files sizes ought to be this (or very close since I may not have accounted for 0 representing first item count):

Now: (218250 * 165) + 540 = 36,011,790
Old: (030464 * 165) + 540 = 05,027,100

Is that what you have, within the margin of error of my calcs?

Another question, could the majority of records be deleted ones? Maybe the code re-writes some tables ... or adds temp tables to the structure and then deletes them? This occurred at the very start of the new year, right? Maybe the app just added a bunch of tables to the database for the new year? Maybe it just closed out the Table16 tables and created new Table17 tables? Something is causing the record bloat over time and that's all I can brainstorm.