--- In IBObjects@yahoogroups.com, "henry FRANQUET" <h.franquet@t...>
wrote:

> ...
> What is the best strategy with IBObject?
> 1) having 2 local databases (one before modification and one after,
> compare the 2 and create queries to update
> 2) use of a table of modification witch key is tableName, keyName,
> keyValue
> 3) another solution
> ....

I don't know what is the best strategy with IBObject, but I can say
what I've used for a POS (point of sale) system (the clients on linux,
kylix, no ibo, a central server, sync over http - client sends and
gets updates from the server over http, on the server a servlet serves
the clients).
Triggers on every table from the local db. Triggers look something
like this:
trigger on table aaa after insert
- insert into tblog 'execute procedure aaa_ins_sync new_values'
trigger on table aaa after update
- insert into tblog 'execute procedure aaa_upd_sync new_values'
trigger on table aaa after delete
- insert into tblog 'execute procedure aaa_del_sync old_key'

When you want to do the sync take all from tblog, compress it (you can
get very good compression on text) and sent it to the server where
it's executed. I used procedures because my replication logic is a
little bit more complicated. If you just want simple replication then
replace the procedures with the insert/update/delete sql.

On the other hand I know there are some replication tools made for
interbase so if your replication is simple maybe you could use those
tools.

ibo seems to have some tools for replication too (TIB_RPL_Meta,
TIB_RPL_Sync) but I didn't used them (and the help doesn't say much).

> b) transfert a file for updating (not as easy to solve dual
> updating on local and server database of the same data)

Solved at the application logic.