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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Progression 7.6.4- data base corrupt files
- Thread starter Micaman
- Start date
Which version of btreive ? We rarely do work with btreive any more, so on my laptop I have P.2000 which is a few years old. I would run the rebuild utility. Please note, you have to backup your data before you run this utility. If you had me running the rebuild, I would even question if restoring the file from backup would be a better approach. The move on to running the rebuild. There are a few other considerations like your create file version setting, as when you rebuild, the system will export the table data, drop the table, create a new table, and import the data at the file version specified.
Best of luck
Best of luck
MacolaHelp
Instructor
We're going to need some more info, here. What version of pervasive including service packs and hot fixes and what server version and patches? Did you reinstall pervasive after the hard drive problem and what compatibility version do you having running?
Error 2 is very serious, 9 times out of 10 a hardware problem. Sometimes the macola and btrieve utilities (which are more sophisticated than macola's) will not detect ascii level corruption. I have had the unfortunate experience of having to find such data corruption by examining a text file for ascii characters. Perhaps there is an automated utility to do this now.
The utility I used to use that Peter refers to is Bsqueeze, which was developed by a former macola reseller. I might be able to locate a copy, but the last servers I used it on were NT4x and netware 5.1. It would not only automate the btrieve save/clone/load in butil, but would also detect file errors such as error 2, 30 etc. I think if you try to export each macola file you may encounter error 2 on files with problems. If you haven't done much file maintenance over the years, you could probably eliminate thousands of records in files like imdisfil, which would make the task of correcting the error 2 easier.
To expand on Peter's post, when I know a hardware problem is a factor, I rename the existing btr file after export and then initialize a new file before importing. If no defrag has been run on your server recently, or if you have let the free disk storage get quite low (under 20%), the files can be very fragmented and the file can be sitting on a bad disk sector. Renaming the file isolates that part of the hard drive so the new file can't sit on a potentially bad spot. What are your storage parameters now and when did you last defrag?
How did the IT house determine there were corrupted files that they didn't write down? Can this utility be run again to examine your current files? You could also try using the btrieve maintenance utility to browse to the various macola btr files. If you try to access the "load information" button, you may get an error 2 on problem files. Identifying there is a problem, though, is different than actually trying to fix it. Sometimes recovering data from a file with an error 2 will only result in a partial recovery.
When was your last good backup? Are you trying to put good data on top of bad right now? If so, your problems will probably get worse unless you get a good set of base files. You could try to run file validations on those you can to find out if you have good master files to work from.
Error 2 is very serious, 9 times out of 10 a hardware problem. Sometimes the macola and btrieve utilities (which are more sophisticated than macola's) will not detect ascii level corruption. I have had the unfortunate experience of having to find such data corruption by examining a text file for ascii characters. Perhaps there is an automated utility to do this now.
The utility I used to use that Peter refers to is Bsqueeze, which was developed by a former macola reseller. I might be able to locate a copy, but the last servers I used it on were NT4x and netware 5.1. It would not only automate the btrieve save/clone/load in butil, but would also detect file errors such as error 2, 30 etc. I think if you try to export each macola file you may encounter error 2 on files with problems. If you haven't done much file maintenance over the years, you could probably eliminate thousands of records in files like imdisfil, which would make the task of correcting the error 2 easier.
To expand on Peter's post, when I know a hardware problem is a factor, I rename the existing btr file after export and then initialize a new file before importing. If no defrag has been run on your server recently, or if you have let the free disk storage get quite low (under 20%), the files can be very fragmented and the file can be sitting on a bad disk sector. Renaming the file isolates that part of the hard drive so the new file can't sit on a potentially bad spot. What are your storage parameters now and when did you last defrag?
How did the IT house determine there were corrupted files that they didn't write down? Can this utility be run again to examine your current files? You could also try using the btrieve maintenance utility to browse to the various macola btr files. If you try to access the "load information" button, you may get an error 2 on problem files. Identifying there is a problem, though, is different than actually trying to fix it. Sometimes recovering data from a file with an error 2 will only result in a partial recovery.
When was your last good backup? Are you trying to put good data on top of bad right now? If so, your problems will probably get worse unless you get a good set of base files. You could try to run file validations on those you can to find out if you have good master files to work from.
- Status