On 9/8/2013 5:53 PM, Helen Borrie wrote:
At 11:53 a.m. 9/09/2013, W O wrote:
>Thank you very much for your answer Helen.
>
>I do backups every day, one full and several incrementals. Well,
rather it is done automatically by my program.
That sounds like nBackup. Restoring from nBackups does NOT reset the
transaction counter. You need to do a gbak backup and RESTORE that
backup to start a fresh counter cycle. How often depends on how fast
you are eating TIDs. Use gstat to monitor that.
>I understand that each commited (and not commited, of course) row
keeps the number of its TID, so that number is always present in the
row. When after a cycle backup/restore the Next Transaction is 1
because all the integer numbers were used, what happens? that database
cannot be used anymore for inserts, updates and deletes?
A database restored from a gbak backup has no transaction artifacts
left from the old database. If you let the TID counter go right up to
the wire with active users then be prepared for corruption in some
shape or form.
Helen Borrie, Support Consultant, IBPhoenix (Pacific)
Author of "The Firebird Book" and "The Firebird Book Second Edition"
http://www.firebird-books.net
__________________________________________________________
OK, this is scary. How do I query the TID to determine if my DB is
approaching the limit?
Lane Campbell
NW Software
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2013.0.3392 / Virus Database: 3222/6648 - Release Date: 09/08/13
