> --- In [email protected], "samcarleton"<scarleton@...> wrote: >> >> raja_s_patil, >> >> Someone else seemed to already have replied with the core questions you >> asked, but there is something you stated which I am finding out in my world >> is a HUGE question and possible show stopper: >> >> -:> Now Client wants to have centralized database with two way Replication >> at HO. >> >> Have you come up with a strategy to replicate the brand databases to the HO? >> If so, have you validated that it will work? >> >> Granted I am working with Interbase 7.5.1 right now and only now starting to >> explorer how to do this for another project using FB2.5/FB3.0. What I am >> learning with Interbase (IB) is that it is going to be extremely painful if >> it is even possible. >> >> In my situation, we want to take data from multiple IB clients and put it >> into one central Microsoft SQL database. Microsoft has developed this very >> power and flexable system called Microsoft Sync Framework. Sync Framework >> can work with any RDBMS, assuming the RDBMS exposes enough info. >> >> Take a look at the Synchronization Example at the bottom of this link: >> http://msdn.microsoft.com/en-us/sync/bb821992 It explains the basic concept >> of how Sync Framework syncs the data. The whole key to it is the "Update >> Tick Count" which is database wide. In the Microsoft world is the @@DBTS >> function. They refer to this function as either the timestamp or as the >> rowversion. >> >> When syncing begins, the sync process needs to be able to get the "minimum >> active rowversion". This is the very last update tick count value used that >> has been commited. >> >> In IB 7.5.1 I don't see any way to get at any value that could be used for >> this. There is a generator, but when you pool the generator, it always gives >> you the very latest value, even if that value is in an uncommited >> transaction. If you use that value as the start of the next sync, all the >> rows in the uncommited will never be synced. If you pick a time that is too >> far in the past, next time the sync happens there will be duplicates. >> >> Internally FB has to have this basic concept since the system works just >> fine when there are 15 active insert transactions and another transaction >> does a select, that select returns the 'safe' values. I am assuming that >> some concept along the lines of 'minimum active rowversion' is being used to >> determine what are the 'safe' rows to return. >> >> So the question is: Does FB expose this type of information to make >> implementing a sync type of process easy or is this concept deep in the >> engine, never exposed, so one needs to hack the whole sync process? >> >> On the IB 7.5.1 project I am simply the developer trying to figure out Sync >> Framework, thus have little say in long term stradegy. For the other project >> where I am looking at FB2.5/3.0, I am in command thus I am starting to look >> at other options. >> >> Sam >> > > Hi Sam, > > We have decided to tryout IBPhoenix IBrepliator for this. For me also this is > First Kind of Task. We thought that deciding would be Database size is First > Step then checking which RDBMS will support is Next. Now since FB 2.5 seems > to be OK so we will evaluate IBReplicator. We can download trial version and > test the replication schema. If needed we can get queries solved in its > Forum. Next 10/15 days we are going to tryout replication and performance > testing of FB before commencement of Actual Project's Development.
For database standby and/or one-way replication requirements you could also try IB LogManager and it's addons. A video on how this works together is available here: http://www.iblogmanager.com/download/demos/iblm/iblm_hotstandby.htm -- With regards, Thomas Steinmaurer * Firebird Foundation Committee Member http://www.firebirdsql.org/en/firebird-foundation/ * Upscene Productions - Database Tools for Developers http://www.upscene.com/ * My Blog http://blog.upscene.com/thomas/index.php
