--- In firebird-support@yahoogroups.com, "samcarleton" <scarleton@...> wrote:
>
>
>
> --- In firebird-support@yahoogroups.com, "fernnaj" <yo@> wrote:
> >
> > Hello,
> >
> > I had the same question time ago, and I posted at MS Forums - please have a look at my post at http://social.microsoft.com/Forums/en-US/syncdevdiscussions/thread/102fd11e-d7ce-479e-a07b-b2e836f3f87e - at the end min_active_rowversion is what we use.
>
> Fernando,
>
> That is EXACTLY the situation I am predicting. In the post you stated "Finally I opted to implement #2, as Firebird does have the same concept", can you give me a bit more info on how to do it in Firebird?
>
> It will be perfect for the project I am just starting and maybe, just maybe Interbase 7.5.1 will have that feature, too, thought I am not holding my breath.

No experience with Interbase, but in Firebird, I use CURRENT_TRANSACTION for the tick count, and MON$OLDEST_ACTIVE-1 from MON$DATABASE for the SelectNewTimestampCommand.

I didn't come up with the solution that Vlad suggests - but I see a potential problem. If I remember correctly, after a restore the transaction number will reset. In that case, if you restore the database, you might eventually have duplicated values in that TranMarks - and that is something you probably don't want.

But MS says that after a restore you should always perform a "fix" on the database (good luck with Reflector, as they only provide code for SQL Server!), and in that case if you use this TransMark table, you would need to somehow clean it or do something with it. Not complete sure right now of what that "something" could be.

The solution with current_transaction and mon$oldest_active-1 is working for us, and together with that extra process while restoring, and lots of hours invested in this monster, the data is flowing between our databases.