| Subject | Re: Does Firebird expose the db wide 'row version'? |
|---|---|
| Author | samcarleton |
| Post date | 2011-10-08T12:51:58Z |
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
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