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
Version: 2013.0.3392 / Virus Database: 3222/6648 - Release Date: 09/08/13