From: "Ann Harrison" <aharri...@nuodb.com> > Dimitry, > >> And exactly this utility is called "replicator". If made right, it >> doesn't need FK >> deactivation and can do "finalization step" when new database is already >> in use. >> Aren't you tired inventing a wheel?.. > > Different vehicles need different wheels. The wheels on my bicycle > wouldn't do at all for a cog-railway and cog-railway wheels work very > badly on airplanes. Airplane wheels are no use at all in a > grandfather clock. Engineering is all about creating new wheels. > Right now, what we're looking for is a wheel that can reset > transaction ids. I'm not sure that either replication or the > mechanism Sean is proposing (similar to either the start of a shadow > database or nbackup) can solve the overflowing transaction id problem. >
Maybe I'm a little dense, (probably :), but doesn't FB already know what the oldest interesting transaction id is? Why couldn't transaction numbers be allowed to wrap back around up to that point? As long as transactions are committed at some point, the oldest transaction would move and it would solve most problems being run into now, IMO. I will accept any and all ridicule if this seems idiotic since I really don't know the code and haven't even looked at it. I'm just amazed and impressed at how easy it is to set up and use FB in everything I do. :) Woody (TMW) ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
