| Subject | Re: [IBO] Field Level Replication in IBO? |
|---|---|
| Author | Helen Borrie |
| Post date | 2003-10-30T11:40:44Z |
At 02:47 AM 30/10/2003 -0800, you wrote:
Firebird. All updates are done by row.
and, at the point of replication (which is one-way), your replication
script goes through and works out a single update or insert statement for
each affected table, based on the newest values in the metadata "stack" for
each column.
replication. They're designed for the briefcase model - children calling
mother to deliver the day's pickings. Because it's possible to hold back a
queue, then, when the child is done, it can ask the mother for its own
update. That is, two one-way replications. But one would always have to
go first.
It would be a logistical handful, that's for sure. You would have to
maintain some kind of a clock-in service on the server so that all of the
children and the mother always knew which updates each had received. There
would have to be some kind of a precedence algorithm for updates: if there
are two or more updates in a day, whose update wins?
Helen
>HiThere's no such thing as "field-level replication" in InterBase or
>
>Does anyone have any experience doing field level
>replication in IBO?
Firebird. All updates are done by row.
>I'm looking to design an application with a largeThe way IBO's replication works is to queue up the metadata for changes
>number of records that get transmitted to
>intermittently-connected clients (who have local
>Firebird databases). The records can be edited at both
>the "host" database and the "client" databases. When
>the clients connect to the "host" system, the edited
>fields should be compared with the host records to
>determine whether to update to log a version conflict.
>etc, etc. Standard replication stuff, but at a field
>level, not a row level.
and, at the point of replication (which is one-way), your replication
script goes through and works out a single update or insert statement for
each affected table, based on the newest values in the metadata "stack" for
each column.
>* What combination of facilities does IBO provide toDirectly, none. IBO's replication components don't support two-way
>support this?
replication. They're designed for the briefcase model - children calling
mother to deliver the day's pickings. Because it's possible to hold back a
queue, then, when the child is done, it can ask the mother for its own
update. That is, two one-way replications. But one would always have to
go first.
It would be a logistical handful, that's for sure. You would have to
maintain some kind of a clock-in service on the server so that all of the
children and the mother always knew which updates each had received. There
would have to be some kind of a precedence algorithm for updates: if there
are two or more updates in a day, whose update wins?
Helen