On 12/28/11 22:51, Leyne, Sean wrote: >> It is feasible to roll over the transaction ID without putting the database >> offline? i.e. when ID is close to limit, reset it to 0 from the code? > In theory there is a "simple" code change which would provide you another 6 > months breathing room. > > But there is no permanent solution which is currently available, and none > that will be available in 6 months. You will need to perform a > backup/restore at some point. > > The "simple" solution is to change the datatype of Transaction related > variables from SLONG* to ULONG. The reality of this solution is, > unfortunately, far uglier given the testing required to confirm that all > references have been changed. > > > Sean > > > * for the life of me I don't understand why signed types where used for > variables which could only contain positive values -- this is a common > problem which is throughout the codebase.
This change was done in trunk. The reason for signed type here was (at least visible reason) very simple - into some functions using same parameter might be passed transaction number (positive value) and something else (negative value). I.e. negative sign meant 'this is not transaction' and function behaved according to it. Please do not treat it as an advice to use trunk in production!!! ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
