At 08:27 AM 4/12/2006, you wrote:

>Hello.
>
>I have been using Firebird / IB since it went open source.
>My database is currently about 9-10 GB stored in one file and probably
>manages between 10000 and 100000 transactions per day for around 40-50
>users. About 100 tables about 300 stored procedures.
>Obviously with that many transactions even an hour's lost data is a
>serious problem.
>
>After about 5 years with only one serious incident I upgraded to FB 2.0.
>
>It has not gone well. In four weeks we have had four corruptions
>ranging from a completely unusable database to blob corruption.
>These have happened on both an i686 multi processor machine and an
>amd64 single processor machine both running the appropriate version of
>SUSE 10.1 Linux.
>
>The only reason we are running at the moment is that I hastily wrote a
>trigger based replication system to continuously duplicate all the
>data changes onto another server.
>
>Each time the corruption has first been noticed during the operation
>of Nbackup which has failed leaving a delta file. In all but one
>occasion the delta merged successfully but a subsequent GBAK failed.

Have you checked and double-checked that
1) you have upgraded your database to ODS 11? NBackup will corrupt
an ODS 10.x database...
2) your users are using the correct client version?
3) the correct client version is available on the server for nBackup
to connect? (i.e. NOT an old client version, and NOT fbembed.dll if
you are using the Superserver version). Be certain about this, as
SuSe has been known to do unusual things with symbolic links.
4) you are running the correct architecture version of Firebird for
each of your deployment cases? (the AMD64 version v. the x86)
5) - if you are running Superserver on x86 - that you have the NPTL
version of Firebird?

And if you need to persevere with asking for troubleshooting help,
then state which model of Firebird server you are using (Classic vs
Superserver).

>An additional problem during the conversion was that the RFUNC UDF
>does not work and will not compile on SUSE. I can get it to compile on
> a Debian machine but it still refuses to work.

RFunc isn't an official Firebird module. IB_UDF and fbudf libraries
are, and have received modifications to accord with Fb 2.0. Have you
tried contacting the author of RFunc? However, "refuses to work" is
not a useful problem statement.

>This forced me to replace all the references to RFUNC with other
>stored procedures using the standard UDF and a bit of extra work.
>
>Now to the questions.
>
>Is there a specification on processor requirements for the different
>versions of FB? Not all 64 bit processors are equal.

True; if you read the release notes, you will see that:
"..the 64-bit ports have been done and tested for AMD64 only. These
builds should also work on Intel EM64T. The Intel IA-64 platform is
not supported in this release."

Some idiot spent many hours putting together a 150-page document
called Release Notes, which you will find in the doc
subdirectory. You **do need** to study them closely - like,
_cover-to-cover_. This is a major release, not just a tidy-up of Fb
1.5; and Firebird release notes *are* the documentation. Just
plonking Fb 2.0 over the top of your faithful old v.1.5 installation
is *not* going to work.

>What version of Linux is FB 2 compiled on? I will install that if it
>helps.

I believe Alex compiles both amd64 and i86 builds on SuSE 10.1 but
you need to verify this by asking in the right forum -
firebird-devel. Get the link for subscribing at
http://www.firebirdsql.org/index.php?op=lists

>Is there any documentation on how Nbackup knows what data has changed?
>It might be a more efficient way to manage the replication than three
>triggers on each table.

Presumably you have read/downloaded the NBackup documentation from
the Firebird website? http://www.firebirdsql.org/manual/nbackup.html

Do you understand that NBackup is not a replication tool?

./heLen