🚀 go-pugleaf

That's why I warned about the potential misunderstanding of the word
"FireBird" : (
I've already seen your strong denials to every post with that word. : � (

"Bill Todd" <no@no.com> escribi� en el mensaje
news:416d61b2@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.