> 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?

Either with gstat or in an ODS 11.1 (or higher) database via the
MON$DATABASE monitoring table.


--
With regards,
Thomas Steinmaurer
http://www.upscene.com/

Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.