--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:

>

Thank you for your prompt response.

> Have you checked and double-checked that
> 1) you have upgraded your database to ODS 11? NBackup will corrupt
> an ODS 10.x database...

I assume that GBAK backup and restore will achieve this. That was the
first step.

> 2) your users are using the correct client version?

Unfortunately I am 800km away. I will reiterate the importance of this
to my contact on site. An errant machine here may well be the problem.

> 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.

Nbackup is running entirely on the server and the cron job points to
the Nbackup inside the /opt/firebird/bin.

> 4) you are running the correct architecture version of Firebird for
> each of your deployment cases? (the AMD64 version v. the x86)

Yes. I have been well aware of the version issue since I started
testing the pre-release versions of 2 some time ago.

> 5) - if you are running Superserver on x86 - that you have the NPTL
> version of Firebird?

Not currently using x86 on a production machine.

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

The classic was abandoned early in the trial as performance became
unacceptable with the number of connections.

> >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.

Thanks but I don't need it now. Refuses to work is shorthand for it
doesn't work and I was under time pressure to get something working so
I abandoned it.

> >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.

I understand that. what I meant is that there are at least two
distinctly different forms of the AMD64 processor. The machine I am
using is a recent one but VMWare for example will only support 64 bit
implementations on certain processor versions.

As for plonking, I installed a clean OS on a new machine with the 2.0
software. I didn't attempt to upgrade the security database, I
recreated the necessary users. I used GBAK to move the DB.

>
> >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
>

Thank you.

> >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

In great detail.

>
> Do you understand that NBackup is not a replication tool?
>

Yes I do.
My 'replication' uses triggers to store the primary key value and
table name in a table. Another machine repetitively queries this table
and writes changes to itself. It is strictly a one way process and I
intend to use a GBAK backup and restore cycle weekly on the slave to
both guarantee that all is well with the DB and cover any possible
imperfections in my copying process.

I suspect NBACKUP may cause some or all of these triggers to fire but
have not investigated that yet.
It just appeared to me that if it can tell what has been changed in
the database between deltas it may be more efficient for me to use the
same mechanism to identify these records.
All I want to do here is ensure maximum data security.

I thank you for your time.

I will ensure ALL the clients are at the correct versions and see how
it goes.
If I still have problems I will analyse the network for hardware
faults as well.


If I still need assistance I will post a thorough analysis of the
corruptions as well.

Regards
Michael Boyle.