At 10:58 PM 31/01/2008, you wrote:

>Hello,
>
>I need to write software, that synchronizes several databases. What I
>need is:
>1) Synchronizing database definitions (one DB serves as master in this case)

I don't know of any replication tool that does that out of the box. It would need to be some special tool that operates in offline mode and takes account of the ownership privileges. On the other hand, any data replication client has to run as a specific user with specific privileges on *data*. There is no way to predict whether that user has owner privileges on existing database objects.

>2) Replicating data among several databases. In this case there is
>always two-way replication.

Any replication tool can be written to do two-way replication. However, it should be obvious that databases that are participating in two-way replication have to be designed to accommodate key conflicts. That is to say, a replication package can't just be "vertically inserted" over a bunch of database copies on different servers where each database is generating its own unique keys.

>Both actions will be performed regulary (once a month expected, but
>possibly more often. It is not expected to live replicating).

It would then be feasible to run some kind of metadata update before running the data update. But again, if you were allowing metadata changes in all zones, you would have to design in some way to control whose changes prevail over the others.

>I saw some components among IBO's, but can't find a good
>documentation/examples about how to use them.

IBO's replication components don't support two-way replication. There is online help there: did you visit it? Even if IBO's replication components are no use to you (and it seems that they won't be) it will possibly alert you to some of the issues concerning replication. http://www.ibobjects.com/docs/RPL_ONLINE/RPL_index.html

>Also, database structure is complicated, so I'm interrested in limits of those components.

If you study the online help, you'll get a better appreciation of what is possible. Basically, at the source database side, each time a record is added, changed or deleted, a record is written to a replication table. When the replication is run, the data in the replication records is used to construct an update, delete or insert statement for the target database. You can also define stored procedures at the target, for which your replication app will pick up input parameters from the replication record and the associated source data record.

>I'm also interrested in alternatives, both components and applications
>for this task. Components/libraries have priority, since we would like
>to integrate these tasks into the software we deploy, but a well working
>external application is also a possibility.

Off-topic here. Ask this question on the firebird-tools list (see http://firebirdsql.org/index.php?op=lists ). You can also do your own research by visiting http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_repl_tools where there are several existing tools you can try out.

Also at the IBPhoenix site you can download the (rather large!) helpfile for IBReplicator. Several of the topics in that document will help you to get your head around the issues of making databases "replicable".

>Once again I warn, that database is a complicated one (not a childish db
>of 5 tables o something similar :))

Most databases would be, if they need to be replicated! :-) But I do reiterate that, no matter how complicated the databases already are, you are going to have to change their structures to make key conflicts impossible. Also, replications are usually time-dependent so you will have to add a time-zone independent timestamp column to every table that you want to replicate. And, if you are planning to do metadata updates as well then all your database objects will need to have some kind of versioning system.

Helen