At 02:57 PM 25-05-02 -0300, you wrote:

>Forced Writes is ON.
>
>Here's the error that my client is getting:
>
>internal gds software consistency check (decompression overran buffer (179))
>
>I also got this error while trying to do a backup with no options. I was
>able to pin-point which table is at fault. Now, I have to find which
>record(s) that is faulty.

Daniel,
I recall that you have been working with unicode in recent weeks. Is it
possible that a unicode value was pushed into a charset NONE column at some
point? I think you could test this possibility by creating a test db and
doing just that; don't query it at all; back up and restore the db and
see whether you reproduce this error.

Here's the theory. The charset NONE column of size n will accept n
*characters*. If you perform a SELECT on a row having a column where the
byte-size of the column is smaller than the byte-size of the data entered
(n * 3, in the case of unicode), you should get a buffer
overrun/transliteration error. When you back up the db, all of the
character data are compressed...then, when you come to restore, this
oversize column decompresses to a byte-length which is longer than the
byte-length of the charset NONE column (which has one byte per character)
and your reported error results.

btw, I'm still convinced that this error:
"internal gds software consistency check (page in use during flush (210))"
which your client encountered, was caused by something external going on
when the database cache was flushed to disk. Even if forced writes is on,
the cache still has to be flushed at the end of a transaction. This error
would have had its source during a write (i.e. at the customer site),
rather than during a read (you trying to read a file-copy of the database).

If you are getting your customers to make file copies of the db for
troubleshooting purposes (e.g. "zip up the database and send it to me")
then teach them to shut down EVERYTHING (including the server) in an
orderly fashion before they start zipping.

Likewise, make it totally clear to them that they must not let a system
backup run over the database directory whilst anyone is logged in. For
safety, I'd want them to have the server shutdown as well if they *must*
include the db directories in their system backups.

I'd really like to collect together some of these "inconsistency check"
errors and document them into one paper.

cheers,
Helen

All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________