Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
visual foxpro 9.0 database 1
- Thread starter Montant42
- Start date
Olaf Doschke
Programmer
Let's define some terminology:
database = DBC
table = DBF
What code do you execute? What error number is the result?
Do you OPEN DATABASE your.DBC?
Do you USE your.DBF?
"Record out of range" errors can result from a GOTO command trying to address a non existing record number. In that case it's not an error about a broken DBF file, just addressing a non existing row.
It's totally unexpected you get such an error from a USE or OPEN DATABASE, unless dbc events are involved. opening a DBC or DBF does not locate at a non existig row, even an empty dbf or a dbc without any tables and views does not make use or open database fail. There has to be something involved, at minimum an index you specify as sort order while opening a table, for example. Specify the failing code.
Bye, Olaf.
database = DBC
table = DBF
What code do you execute? What error number is the result?
Do you OPEN DATABASE your.DBC?
Do you USE your.DBF?
"Record out of range" errors can result from a GOTO command trying to address a non existing record number. In that case it's not an error about a broken DBF file, just addressing a non existing row.
It's totally unexpected you get such an error from a USE or OPEN DATABASE, unless dbc events are involved. opening a DBC or DBF does not locate at a non existig row, even an empty dbf or a dbc without any tables and views does not make use or open database fail. There has to be something involved, at minimum an index you specify as sort order while opening a table, for example. Specify the failing code.
Bye, Olaf.
- Thread starter
- #3
Olaf Doschke
Programmer
The two ways are for two different things, you cannot open a dbf via OPEN DATABASE.
Do you open by double clicking the file? What file type and extension?
Bye, Olaf.
Do you open by double clicking the file? What file type and extension?
Bye, Olaf.
- Thread starter
- #5
Olaf Doschke
Programmer
I was not suggesting what to do, I asked what you did, when you said you opened the DBF.
Bye, Olaf.
Bye, Olaf.
Olaf Doschke
Programmer
At least we know know you opened a TABLE, and not a database.
Do you see a DBC file anywhere near this DBF file?
Start up VFP and in the command window execute [tt]DO HOME()+"Tools\hexedit\hexedit"[/tt].
Select your DBF file.
What is displayed as first byte of address 00000000?
Bye, Olaf.
Do you see a DBC file anywhere near this DBF file?
Start up VFP and in the command window execute [tt]DO HOME()+"Tools\hexedit\hexedit"[/tt].
Select your DBF file.
What is displayed as first byte of address 00000000?
Bye, Olaf.
- Thread starter
- #8
Olaf Doschke
Programmer
If you would answer questions, I could be of help, but you have many open questions:
Answered so far:
Do you OPEN DATABASE your.DBC? Do you USE your.DBF?
Partial answer: The problem is about a DBF file, you don't answered how you opened it. Less important, maybe.
Open questions:
[highlight #FCE94F]I asked what you did[/highlight], so far no answer. The only thing you said double click won't open it.
[highlight #FCE94F]Do you see a DBC file anywhere near this DBF file?[/highlight] No answer so far.
I wanted you to start up VFP and in the command window execute DO HOME()+"Tools\hexedit\hexedit".
Select your DBF file.
I asked [highlight #FCE94F]what is displayed as first byte of address 00000000?[/highlight] No answer so far.
[highlight #FCE94F]New question:
Do you have FoxPro at all?[/highlight]
Knowing your error is obviously not at all enough to know what's going on with your DBF file. If it would be enough to know, I would already have told you what to do.
My assumption on the base of the little knowledge I have about your case is, that the DBF is a healthy file, but any code in a DBC event causes to move to a non existing record number. Maybe that DBF contains some expected number of rows and was emptied, at least the DBF is most likely having too little records. We never know, if you don't cooperate. You are our eyes and hands, without you reacting and answering questions, there's nothing more, we can do for you, no matter how you beg for aid.
Bye, Olaf.
Answered so far:
Do you OPEN DATABASE your.DBC? Do you USE your.DBF?
Partial answer: The problem is about a DBF file, you don't answered how you opened it. Less important, maybe.
Open questions:
[highlight #FCE94F]I asked what you did[/highlight], so far no answer. The only thing you said double click won't open it.
[highlight #FCE94F]Do you see a DBC file anywhere near this DBF file?[/highlight] No answer so far.
I wanted you to start up VFP and in the command window execute DO HOME()+"Tools\hexedit\hexedit".
Select your DBF file.
I asked [highlight #FCE94F]what is displayed as first byte of address 00000000?[/highlight] No answer so far.
[highlight #FCE94F]New question:
Do you have FoxPro at all?[/highlight]
Knowing your error is obviously not at all enough to know what's going on with your DBF file. If it would be enough to know, I would already have told you what to do.
My assumption on the base of the little knowledge I have about your case is, that the DBF is a healthy file, but any code in a DBC event causes to move to a non existing record number. Maybe that DBF contains some expected number of rows and was emptied, at least the DBF is most likely having too little records. We never know, if you don't cooperate. You are our eyes and hands, without you reacting and answering questions, there's nothing more, we can do for you, no matter how you beg for aid.
Bye, Olaf.
-
1
- #10
I know that Visual FoxPro it is very complicated program. Especially for it was created DBF Restore Toolbox, it helps to get .dbf files back after any level of corruption –
Olaf Doschke
Programmer
I doubt hinting on repair tools will help.
Broken DBFs have the error message "Not a table" (Error 15) or you can have "Database is invalid. Please validate." (error 1561) when opening a broken DBC.
If the cdx is corrupt "Index file does not match table" (Error 19)
There are a few more reported because you can't open the table due to permission issues or locks, but not because its corrupt.
Then there are structural errors not seen while opening but when using the table, eg if the table has memo field there is a FPT file and the DBF has offset pointers going into that FPT. It would be doable to check all offsets are within the FPT file size, but as with the index nodex pointing to possibly not existing recnos, this can be broken and will only sho so, if you access such a memo field. It would be unbearable any opening would check every such pointer or reference of validity.
The error you mention, Montant42, is error number 5 and is explained by:
Access to any record other than recno 1 doesn't happen from just opening a table. So opening a table alone doesn't move to any record not existing. If there is no record number 1 the same position will be the end of fily mark byte and thus the normal opening position of a DBF right after the DBF header always exists and doesn't cause ERROR 5. You'd have to open with an index/sort order to let the index position on the first record in index order. Then such an error might happen with the index out of sync with the DBF data, containg index nodes pointing to a non existing record.
But if you even can't tell how the table is opened, eg with specifying an index sort order, I can only guess and make assumptions and that's in general not a final truth and not helpful.
If you're just a user of an application written in foxpro or similar langueage using dbfs to store data, you should contact the vendor of that application.
You expect there'll be a simple way to fix all corruptions, ther isn't.
Even if you get a DBF working again and it turns out there was something in there or in a related file like FPT or CDX or IDX or DBC, you should also compare with a restored backup, especially what changed in the records fixed. And most such end user tools will not tell you which recnos they fixed, so it's hardly comparable to what you might be able to restore from your backup.
A table is not a car or something like that, an object with a defined structure and its motor compartment, tires, brakes. You can re4place that, but no car mechanic will fix your broken or lost trunk contents. Not because it's not his job, but because if there is something missing he can't know what was there. If there is a broken milk bottle he can conclude this was a whole bottle, but it might already have been half emptied before it broke.
In a DBF, if you find part of text, you might guess and reconstruct something, as with any text in any file type. The problem with broken dbfs is they mainly are the trunk and not a structure with parts that need to be at defined places like the motor compartment. You only have the header and the rest then is data. As already said you also have pionters from DBF to FPT files and from CDX to the DBF file. Then you have the deletion mark bytes, which should only either be space or "*", but all other bytes are not limited to a restricted set of valid values. An int for example has 4 bytes and any byte value is possible in all 4 of them. You can't detect a broken int field and repair it with any tool, for that reason, and that's just one example.
Bye, Olaf.
Broken DBFs have the error message "Not a table" (Error 15) or you can have "Database is invalid. Please validate." (error 1561) when opening a broken DBC.
If the cdx is corrupt "Index file does not match table" (Error 19)
There are a few more reported because you can't open the table due to permission issues or locks, but not because its corrupt.
Then there are structural errors not seen while opening but when using the table, eg if the table has memo field there is a FPT file and the DBF has offset pointers going into that FPT. It would be doable to check all offsets are within the FPT file size, but as with the index nodex pointing to possibly not existing recnos, this can be broken and will only sho so, if you access such a memo field. It would be unbearable any opening would check every such pointer or reference of validity.
The error you mention, Montant42, is error number 5 and is explained by:
VFP help on error 5 said:
Access to any record other than recno 1 doesn't happen from just opening a table. So opening a table alone doesn't move to any record not existing. If there is no record number 1 the same position will be the end of fily mark byte and thus the normal opening position of a DBF right after the DBF header always exists and doesn't cause ERROR 5. You'd have to open with an index/sort order to let the index position on the first record in index order. Then such an error might happen with the index out of sync with the DBF data, containg index nodes pointing to a non existing record.
But if you even can't tell how the table is opened, eg with specifying an index sort order, I can only guess and make assumptions and that's in general not a final truth and not helpful.
If you're just a user of an application written in foxpro or similar langueage using dbfs to store data, you should contact the vendor of that application.
You expect there'll be a simple way to fix all corruptions, ther isn't.
I would be cautious making such assertions. If a file has a corrupt block not having the original, you can't get it back any way, all such a software could do is put back a healthy dbf structure at such missing blocks, but it can't know the content of the "fixed" rows. Many defects can only be replaced by blanked fields, so the DBF can be used again, but has data lost.tightog said:
Even if you get a DBF working again and it turns out there was something in there or in a related file like FPT or CDX or IDX or DBC, you should also compare with a restored backup, especially what changed in the records fixed. And most such end user tools will not tell you which recnos they fixed, so it's hardly comparable to what you might be able to restore from your backup.
A table is not a car or something like that, an object with a defined structure and its motor compartment, tires, brakes. You can re4place that, but no car mechanic will fix your broken or lost trunk contents. Not because it's not his job, but because if there is something missing he can't know what was there. If there is a broken milk bottle he can conclude this was a whole bottle, but it might already have been half emptied before it broke.
In a DBF, if you find part of text, you might guess and reconstruct something, as with any text in any file type. The problem with broken dbfs is they mainly are the trunk and not a structure with parts that need to be at defined places like the motor compartment. You only have the header and the rest then is data. As already said you also have pionters from DBF to FPT files and from CDX to the DBF file. Then you have the deletion mark bytes, which should only either be space or "*", but all other bytes are not limited to a restricted set of valid values. An int for example has 4 bytes and any byte value is possible in all 4 of them. You can't detect a broken int field and repair it with any tool, for that reason, and that's just one example.
Bye, Olaf.
- Status
