|Subject||RE: [ib-support] Replication (more)|
|Author||David R. Robinson|
We had/have the same "problem" with our commercial application. Our solution is to have our application support multiple database engines (InterBase, Oracle, MS SQL Server, Sybase & Informix). InterBase is the "default" database, but if someone is an Oracle shop, we aren't going to get them to change. This also covers situations like when people want over 1000 concurrent users on one database--which InterBase can't handle. This may not be an option for you, but I thought I'd at least mention it.
There are pro and cons to doing this versus replicating the data. We chose this approach in 1995 and have pretty much stuck with it since it has worked well for us.
From: fabrice.aeschbacher@... [mailto:fabrice.aeschbacher@...]
Sent: Monday, March 05, 2001 8:54 AM
Subject: [ib-support] Replication (more)
Some customers already have their database server, say Oracle or
SQL/Server, and do not want to change. In such a case, if we want to
keep our application based on IB, the idea would be to replicate all
changes made to IB DB into the external DB.
The solutions I can imagine are:
1) Write triggers (for each table we want to replicate) which call an
UDF to update Oracle table (But how to maintain the connection with
the Oracle DB between UDF calls?)
2) Make trigger log all data changes in a DATA_LOG table and raise an
event. Then write another application (service?), connected to both
IB and Oracle DB, listening to IB events, and writing all changes in
Oracle DB as indicated in DATA_LOG table.
(http://www.interbase2000.org/doc_calford_1.htm#rollforward gives an
example of master/detail table for storing data changes)
-What do you think about these 2 mechanisms?
-Do you see another solution?
-What about stability (particularly when network connection is not
active between the 2 DB servers)?
To unsubscribe from this group, send an email to:
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.