We find ourselves in the unfortunate position of having a major problem with old Clipper application without anyone on staff with any Clipper knowledge at all.
We were happy as pigs in mud with a Clipper application that has been running maintenance free for several years, with the occasional packing and reindexing. We knew that we would eventually have to replace the application, but it was always pushed to the back burner.
Last week, one of our .dbt files went over 16MB and we've had problems ever since.
We searched the web and tried to rectify the situation by...
(1) thru DBU, copying the .dbf to another file
(2) zapping the offending .dbf
(3) appending the copied .dbf to the original
Unfortunately, we could never make it through Step#1 above because our copy would hang up after running for 3 minutes or so. On two occasions, we let the copy run for 2 hours and the new file size never increased beyond what it had reached after 3 minutes.
We had a backup of the offending .dbf and .dbt, so we were willing to lose what was in the live system in those 2 files and continue. So...
(1) thru DBU, I zapped the offending .dbf
(2) then packed
(3) then started the ap... which prompted me that the file was empty, would I like to add a record, which I did, then I packed again and all appeared fine. The .dbf and .dbt were tiny and I thought all was well.
The ap ran fine for a few hours but then (don't know what caused it), we received an error in the ap when trying to maintain the offending file on a specific record. I deleted the offensive record, ran the ap again and then it appeared as if all the .dbf records had lost their pointers to the .dbt. No memos appeared at all.
I have repeated the process above a few times with varying approaches...(a) doing through DBU, (b) through DBASE, (c) Zapping, copying and then appending... all with the same result. The new .dbf and .dbt files appear to function fine for a few hours... or a few maintenances... but eventually they fail.
Obviously, I am willing to trash what is in this particular .dbf and .dbt and start over. However, although the ZAP appears to clear out the file, we continue to have problems. The file must be corrupt and the ZAP won't fix it.
With no Clipper knowledge & no DBASE knowledge, we're in big trouble. I would appreciate any comments at all in regard to this problem. How can I fix a corrupt file... or how do I determine the structure of the file so I can delete it and then redefine it and it's corresponding .dbt WITHOUT having to get into any Clipper code.
Help? Please. And, yes, replacing that application has been moved to the front burner!
The DBT file is tightly wedded to the corresponding DBF file. While they are two physical files, logically they are one.
If your file is undamaged, just overly large, then you can use DBU.EXE or a similar utility to copy the old file into a new one (which will be implicitly packed in the process).
If your file is damaged and you want to recover data, then you'll probably need to get a Clipper user involved. The exact process varies slightly depending on the type of damage, but it isn't often rocket science to fix things.
It sounds like you may have some corruption in the dbf file. I've seen a number of different files that have become corrupt and have manually browsed the data, found the corruption and cleaned it up. You didn't mention if you were coping the data out with the index open or not but the index could be corrupt as well and you would need to erase the NTX file and recreate the index fromscratch to clean that up. The only way to identify if you have corruption in the dbf is to visually inspect the data. Visual FOXPRO does a good job of letting you browse a corrupted fiel were as DBASE doesn't always.
The other thing is have you changed the OS on the desk top or server? I've seen that cause corruption as well.