From Borland:

Most likely the database was either straight file copied between the
two _different_ platforms or a non-transportable backup was restored
from the Windows machine to the NetWare server. In either case, the
database should be backed up as non-transportable and then restored.

Note: This error may even occur on the same operating system if the
file systems are of different types (for example, FAT16 and NTFS).

Note: A similar error ("internal gds software consistency check
(wrong record length (183))") may also occur for the same reason and
the same steps above can be used to resolve it.

---

So the question is, how was the db created on that machine (non-
transportable backup?), and if it was copied were the source and
target file systems the same?

Regards,
Andrew Ferguson
-- Approved by a committee of dangerously stupid men.

--- In ib-support@y..., "paolo_fainelli@l..." <paolo_fainelli@l...>
wrote:

> Hi all,
>
> I have an application written in Delphi 5. Backup of database is

done

> with TIBBackupService (InterBase Express).
>
> AFTER the backup ( backup file is ok...) database file get

corrupted,

> and this is the server log:
>
> .
> .
> .
>
> SERVER (Server) Wed Jul 24 08:43:12 2002
> Database: C:\PROGRA~1\EUREKA\DATABASE\DBDITTE.GDB
> internal gds software consistency check (decompression overran

buffer

> (179))
> .
> .
> .
> .
>
>
> ...and this is the messages doing a command line backup.
> gbak: writing data for table D001B10TTESTA
>
> gbak: ERROR: internal gds software consistency check (decompression
> overran buffer (179))
>
> gbak: ERROR: gds_$receive failed
>
> gbak: Exiting before completion due to errors
>
> gbak: ERROR: internal gds software consistency check (can't

continue

> after bugcheck)
>
>
> Database situation AFTER backup
>
>
> Database header page information:
> Flags 0
> Checksum 12345
> Generation 414189
> Page size 8192
> ODS version 10.0
> Oldest transaction 414114
> Oldest active 414177
> Oldest snapshot 414177
> Next transaction 414178
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 0
> Implementation ID 16
> Shadow count 0
> Page buffers 2048
> Next header page 0
> Database dialect 1
> Creation date Mar 28, 2002 8:52:49
> Attributes force write
>
> Variable header data:
> Sweep interval: 20000
> *END*
>
>
> My customer was using WIN98, firebird 1.0, the was no crash between

the

> backup and other operation.
> A gfix resolved the situation, but i'm a little scared, because i

don't

> know what could be happened....
>
> Any idea ???
>
> Paolo