At 06:01 PM 11/10/2004 +1000, you wrote:

> > > did you make sure all clients were updated?
> >
> > No. Is it absolutely necessary?
> > Old clients should not be able to corrupt the database!
>
>if all client libs were the same, then maybe not but if there is a total
>mismatch of client libs and an old app is using an old client lib with a
>different connection string to the new apps/client libs, then there is a
>good chance of corruption.
>e.g. IB6 client with a local connection string on the local box Vs FB1.5
>client lib with a TCP connection string...

Clients can't connect to a Firebird database with a "bad" connection string
at all - regardless of which client is being used.

And, no, a client *library*, per se, can't corrupt data pages. A bad
client application interface can corrupt data, sometimes
untraceably. Take, for example, the supreme ignorance of most Delphi
components to the problem Interbase and Firebird 1.0 had (have) with
scrambling return values from stored procedures. IBO worked (works) around
this; the others don't. The problem was fixed in Fb 1.5, which then
"created the problem in reverse" for IBO.

In summary, attaching an old IBO app (pre IBO 4.3) to a database under a Fb
1.5 server has the potential to cause corrupt data (worst case) or puzzling
exceptions (best case) if the server isn't configured with
OldParameterOrdering set true.

But inconsistent page chains aren't caused by bad user data. For these,
look for traumatic causes: a dying hard disk, someone running a filesystem
backup while the database is active, someone using Winzip to copy an active
database, yada yada yada, someone connecting to the database during a
-r[eplace] restore.

Given the recent history of 5/6 days running under a restored database, I'd
be suspicious about the health of the disk. Did you do a scandisk before
restoring the transportable backup into 1.5? Is this a multi-file database?

./heLen