--- In firebird-support@yahoogroups.com, Rodrigo Gonçalves
<rglistas@f...> wrote:

> Hi,
>
> in one of our clients the following errors ocurred in the last

friday( I

> got this from the Firebird log):
>
> (Server) Mon May 10 13:13:20 2004
> Database: /manager/gdb/EcomaxUBR2000.GDB
> internal gds software consistency check (wrong record length (183))
>
> Soon after the following errors ocurred too:
>
> (Server) Fri May 14 14:37:57 2004
> Database: /manager/gdb/EcomaxUBR2000.GDB
> internal gds software consistency check (wrong record length (183))
> (Server) Fri May 14 14:39:00 2004
> Database: /manager/gdb/EcomaxUBR2000.GDB
> internal gds software consistency check (wrong record length

(183))

> (Server) Fri May 14 15:18:09 2004
> Database: /manager/gdb/EcomaxUBR2000.GDB
> Index 15 is corrupt (missing entries) in table CL_PACIENTES (215)
> (Server) Fri May 14 15:18:43 2004
> Database: /manager/gdb/EcomaxUBR2000.GDB
> Relation has 1 orphan backversions (1264 in use) in table
> CL_ATENDIMENTOS (266)
> (Server) Fri May 14 15:18:44 2004
> Database: /manager/gdb/EcomaxUBR2000.GDB
> Index 8 is corrupt (missing entries) in table CL_CONSULTAS (267)
> (Server) Fri May 14 15:18:44 2004
> Database: /manager/gdb/EcomaxUBR2000.GDB
> Page 216647 is an orphan
>
>
> The system was running the Firebird 1.5 RC6. I've followed the

Changelog

> for Firebird but found nothing regarding if something that could
> originate this error was fixed. Anyway, I've recommended changing the
> the FB 1.5 Final release.

Recommendation is good, but I don't think this will be enough.

> My question is, what could originate this errors? I assure the system
> wasn't uncleanly shutdown and the hardware is OK. May the fact that the
> clients are using IBX and some still use BDE (some for long running
> transactions) cause this? Also I've found out that clients even used

the

> IB client libraries instead of the the FB one. I recommended the

changes

> too.

Usage of IB client against FB is not good, but I don't think this
can cause database corruption. Nor IBX neither BDE usage can't lead to
such a corruption.

> Analysing the database, I've found that the oldest transaction (not the
> oldest active) was very, very far from the next transaction
> (1108,1535038). Could this also originate the problem?

Hmm, gap itself should'nt be reason for database corruption, but I
never saw so large one. Usually in such circuimstances server terribly
lose performance till the complete "hang" state on queries on most
garbaged tables and unexperienced admin or user kill server process.
Don't believe person who assured you that system wasn't uncleanly
shutdown - there are not another chances to get orphan versions, at
least I don't know another methods to get them.

> Also a backup/restore of the database was done 2 weeks ago.

Choice time interval when you can stop work of your clients and
perorm sweep in this time. I make in nightly using cron (AT on Win),
on well-designed database and access this should consume much time.
Sweep will move oldest transaction (I believe in your case it was
rollback of the transaction which modified rather large amount of
data). If rolled back transaction's changes can't be undone by server
"on the fly", this transaction becomes oldest (if there is not more
oldest rollback already). Sweep converts state of rolled back
transactions to "commited" and forces collection of garbage which is
hold by them.

Best regards,
Alexander.