Can anyone tell me how to solve this problem I've been working BTrieve quite
a wile ago and one of our customers is still working with an old
application.

The website says:

"During a Get or Step operation, the MicroKernel could not read all or part
of the variable-length portion of a record. The MicroKernel returns as much
data as possible to the application. This status code usually indicates that
one or more pages used to store variable-length records are corrupt. Check
the data buffer length the MicroKernel returns to see how much of the record
was returned. Recover the damaged file as described in Pervasive.SQL User's
Guide. "

Unfortunately we and they don't have this user guide.

I used BUTIL -RECOVER to recover the file
then BUTIL -CREATE to create a new file
and BUTIL -LOAD to load the file again but without any luck. Now I get error
22

This is the only thing I could remember from the old days.

Any help would be greatful.

thanks,

Frank Vestjens
InforIT bv

On Wed, 3 Dec 2003 16:31:15 +0100, "Frank Vestjens"
<FVestjens (AT) InforIT (DOT) nl> wrote:

If the customer is running a Btrieve server engine on Novell, he may
be experiencing "phantom corruption". To verify this, do a DOS copy of
the file (back and forth) and check if the problem persists.

<snip>
Apparently you used the wrong description file to create the new file;
one with a longer fixed record length. You should have better luck
with the -CLONE option.



Gordon Bos
Q-RY Solutions
+31-(0)15-2564035

http://www.q-ry.nl/

I'd be interested to see the BUTIL -STAT of the file to see if data compression
is turned on.

When you rebuilt the file, which is really the only way to resolve the Status 54
problem, one of the compressed records may have had a single-bit error in it.
If this fell in exactly the right location, it would cause the decompressed
record to be MUCH larger than the original record sizes, which would then cause
a recovered record written back into the file to be too big for the application
to load -- resulting in a Status 22.

There are three options:
1) Stick with your current file: You will need to find the offending record,
then either delete or shrink this record. Doing so is easy only if you know
Btrieve, and moderately difficult otherwise. Luckily, the 32-bit Function
Executor (provided in versions since PSQL2000) is a wonderful help in all this,
although it is possible (though much more complicated) to use the 16-bit version
(WBEXEC).

2) Repair the original file again: This will cause data loss from any recently
added, deleted, or updated records, but would be a better way to recover the
database. Often, a thorough understanding of the data structures and the
compression algorithm can lead to a way to repair the data. This is not
something for the faint of heart or the technically challenged, but if you can
read hexadecimal and don't mind wading through the Btrieve Complete text, as
well as hacking at a file with a hex editor, then you'll be able to repair it
yourself. Of course, both myself and Jim Kyle (author of Btrieve Complete)
perform data recovery for hire.

3) Restore from backup: You may need to restore the entire system from backup,
depending on relationships in the data. Or, you might be able to restore just
this one file. Of course, restoring this one file to find the original record
that was damaged, then putting this record back (a la option #1) might be
feasible if you know what you're looking for.

Hopefully, this helps...
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: March, 2004: See our web site for details!


Frank Vestjens wrote:

Thanks guys.

I've informed the customer and told them to quit the current file and start
with a new file from scratch. Reporting shoul be done on the old file and on
the new file to get a full overview.

So far they haven't had any problems since.

Frank Vestjens
InForIT bv