Subject | Re: Need help with errors |
---|---|
Author | csswa |
Post date | 2002-05-30T09:55:44Z |
Hiya Daniel.
Sorry if I seem a bit grumpy today :-)
Sorry if I seem a bit grumpy today :-)
--- In ib-support@y..., Daniel Rail <daniel@a...> wrote:
> Thanks Andrew for your reply. It's greatly appreciated.
>
> I know that I did ask, in the past few days, about some of the
error
> messages that I mentioned in my latest post. I didn't have my
client's
> actual log at the time and was feeding the error messages out of
mine. The
> message that I posted yesterday contains the log entries from my
client.
>
> There is at least one error that I'm curious about, and that's the
first
> one in my latest post, which is:
> NTSERVER (Server) Tue May 21 23:26:09 2002
> Database: C:\PROGRA~1\FILOPTO4\DATA\FILOPTO.FDB
> internal gds software consistency check (wrong record length (183))
If you haven't found this (by Ann H.) already in your google
searching :-) ... Can't see how it applies in your case, but maybe
you will get some clues.
Problem:
I am getting
"internal gds software consistency check (wrong record length (183))"
and
"decompression overran buffer" errors when I try to gbak my
database.
Solution:
The "(183)" means that the internal message table number for the
"wrong record length" message is 183, not that the record was, or
should
have been, 183 bytes (or words or bits) long. This does not help you
to
figure out what could be causing the difficulty. It just points out
the internal
message number that this error triggered.
As you probably know, records are compressed before being stored on
disk. When they are read, they are decompressed into a fixed length
buffer that is the full size of the record. It should fit exactly.
If the expanded data is too long, you see a message
like "decompression
overran buffer". If it's too short, you get the "wrong record length"
error.
The most common reason was copying a database file between
architectures -
different operating systems or different processor types. For
example,
copying a database from NT to Novell can cause errors like this.
That's
why a transportable backup is the preferred way to move databases.
The
underlying problem is that different architectures use different
alignments
for different datatypes and if the alignments don't match, neither
does
the data.
Source : Ann Harrison on the listserv