"Bill Todd" <n...@no.com> escribió en el mensaje
news:416d...@newsgroups.borland.com...
> You need to contact IBPhoenix about that. This group is for the
> IBReplicator that ships with InterBase, not the Firebird variant.
>
> --
> Bill (TeamB)
> TeamB cannot answer questions received via email
>
> Sergio H. wrote:
>
> > <I wanted to post here this message (rejected in some other
> > newsgroup)... if someone reading this would be so nice of assuming
> > that the word "FireBird" is "InterBase 6" or any similar.>
> >
> > Greetings,
> >
> > We've installed IBReplicator 1.5.5.0 in order to keep two FireBird
> > 1.5.0.4306 databases up to date. The first one, which will be the
> > "source", under Windows 2003 Small Business Server. The second one,
> > that will be the "target", under SlackWare 9.1.0 kernel 2.4.22.
> >
> > 1.) Just after I installed the Replication Server on the Windows
> > server and defined the configuration, I wanted to backup that
> > database and restore it on the Linux server. When restoring, it
> > always says :
> >
> > gbak: ERROR: unsuccessful metadata update
> > gbak: ERROR: object XXX is in use
> > gbak: ERROR: action cancelled by trigger (3) to preserve data
> > integrity gbak: ERROR: Cannot deactivate primary index
> > gbak: Exiting before completion due to errors
> >
> > Where XXX is the name of a table, different in each restoring attempt.
> >
> > So, I thought it has to be with the "Replication Server's System
> > Objects", and using the Replication Manager I removed them from the
> > Source database. Nothing changed when trying to restore it, the
> > error continued there.
> >
> > Then, I looked for traces of REPL in the database and run :
> >
> > DROP GENERATOR REPL_GENERATOR;
> > DROP TABLE REPL_LOG;
> > DROP TABLE REPL_SEPARATOR;
> > DROP TABLE MANUAL_LOG;
> >
> > Again, nothing changed when trying to restore it, the error continued
> > there.
> >
> > 2.) When this replication schema is working, and I look to the
> > Replication Server Monitor, I notice the error count grow
> > exponentially.
> >
> > The first thing I did, was to check the Manual Conflict resolution
> > dialog and found that the server had problems with some primary keys.
> > Almost 99% of the tables use a primary key, which (integer) value is
> > generated by a "before insert" trigger calling a generator to
> > increment its value by 1. Being that so, new records in the "source"
> > database will have sequential key values (i.e. 1001, 1002, 1003,
> > ...), but in the "target" the expected key values go in a strange
> > sequence (i.e. 1001, 1005, 1008, ...).
> >
> > Does anyone know about this issues using IBReplicator ?, and how to
> > get rid off them ? I'd appreciate any help.
> >
> > Regards,
> >
> > Sergio H. Guerrero R.