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

 

[Olaf Doschke]

OK, you have the file triple, but still not the whole database in the sense of all files making up the database, inlcuding tables, right?

That shouldn't be a problem in regard of OPEN DATABASE, but you might have DBC events needing some DBF. That would cause file not found or similar errors though, not ERROR 1552.

You still have to get to the bottom of the reason why this error occurs and it has to be within the objecttype='Database' rows. Nothing else can cause a validation error of the DBC, besides any structural defect. But as you can open the dbc as a table, this isn't a problem. OPEN DATABASE doesn't care about existence of tables or fields or indexes, this isn't checked in the moment of OPEN DATABASE.

Do you see these fields and rows in your defect DBC?

You said you have many objectid=0, are these deleted? objectid is a sequal number, an id, starting with 1 and being >1 for all rows. this hints on a problem. I just tried and created and dropped a table, altered a table, and this results in deleted rows, but their objectid stays as it was, the objectids of undeleted rows will have gaps, but not be set to 0.

Most likely this is causing your problem, though I just tried to recall some deleted rows and give them objectid=0 and it still didn't led to ERROR 1552.

What your version of VFP?

Bye, Olaf.

 

[Foxtrotter]

Yes, I do see those first five rows matching yours. There are no deleted rows in the database. I have packed it and it still shows the same number of records. I also tried removing those objectid=0 records but it did not help.

By the way, I have now downloaded all the data files as well so if I have time today, I will see if that makes any differences at all.

 

[dbMark]

I was the one who first mentioned error 1552, based on Foxtrotter's error description. So maybe don't focus on an error number unless it's confirmed.

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

So if you open the DBC as a table can you determine what those other records are, the ones where Objecttype is not Database, Field, Index or Table?

 

[Olaf Doschke]

OK, what do you get if you output property from the first row?

[tt]? CREATEBINARY(property)[/tt]

to copy this over here, do [tt]_CLIPTEXT = Transform(CreateBinary(property))[/tt]

For my healthy DBC this is 0B0000000100180000000A

And do you see something in the StoredProceduresSource Code memo?

Bye, Olaf.

 

[Foxtrotter]

Hi Olaf,

Yes, mine looks to match yours: 0B0000000100180000000A. I do not see anything in the code memo for StoredProceduresSource. As a matter of fact, I don't see anything in the code memo for any of the records.

 

[Olaf Doschke]

Then one last possibility I see is your VFP version is not matching the DBC. So what VFP version do you have?

Bye, Olaf.

 

[Foxtrotter]

That is a possibility. I am using VFP 9 with services packs. How can I tell what version the database is?

 

[Olaf Doschke]

You already told the DB is version 8, but then forget about that reason. VFP9 is totally capable to open databases of any VFP version.

Bye, Olaf.

 

[Olaf Doschke]

If the error is not within the first 5 records, it could be in the rest of the dbc data. So make a copy and in the copy DELETE FOR RECNO()>5

Then try to open that empty DBC via [tt]OPEN DATABASE[/tt]. If that doesn't work, you have an error in the header of the DBC file. You may not detect it with [tt]USE[/tt], if you have unset tablevalidation, but [tt]OPEN DATABASE[/tt] still does this validation.

So, if that shrinked down DBC does not work, the recreation of a healthy DBC could be by creating a new DBC, using it as table, zapping it and appending the data of the not working DBC, renaming the files to match the old ones and give that replacement DBC a try.

And if the shrinked DBC does open, you know at least the culprit is somewhere in the DBC data, then you know what to look into, at least, most probably somewhere in the latest records.

Bye, Olaf.

 

[Foxtrotter]

Hi guys,

I have had a breakthrough. Unknown to me, there was a data folder on one of the systems that contained a copy of the DBC and data tables that only contained sample data. I was able to copy that DBC over and get the system to work. I did have a few tables that it would not relink to the database, but I was able to rename those tables, copy the sample table and index files over then delete the sample data and append from the current table and get them to work.

The system isn't fully tested yet but it looks promising.

Thank you all for your help. I just wish we had known about that option several days and many hours ago.

Olaf, I did have a chance to try your option somewhat in that I created the database and was able to use open database and even validate it but the tables were not linked and many of them would only give me the "delete" option to remove them from the database. It might have been possible to continue down that path to re-link those tables though.

 

[Olaf Doschke]

Well, you misunderstood. When deleting data and only keeping the first 5 rows of course no table remains part of the DBC. With no meta data about them the DBC doesn't know them.

This was just a first step in finding out what was corrupt. Would have been nice to know what was the matter. If the DBC still wouldn't have opened the usual header count fix would have solved it most probably. If the problem was in the rows, you could have added back data one table after another and identify the problematic one. Well, in short there was a larger plan, but I didn't reveal it fully because it had a lot of if-this-then-that-else-the-other-thing branches and that makes it cumbersome to tell you in advance.

Bye, Olaf.

 

[dbMark]

Probably that DBC with sample tables was a much smaller size than the 35MB one from earlier this month. Needless to say, once you have it all working again you'll ensure multiple backups are made. It would be interesting to track this from week to week, month to month or year to year to determine how frequently the DBC bloat/whatever occurs.