Re: [firebird-support] UPDATE to same record causing heavy disk I/O

Hi Caroline, It could be a chain of many record versions. If you have such database handy, run gstat -a -r > stat.txt and load it to HQbird Database Analyst (trial version will be enough), then open tab Tables and sort on Max Versions column. Check how many versions on the table you are

Re: [firebird-support] UPDATE to same record causing heavy disk I/O

On Wed, Dec 23, 2015 at 7:12 AM, Alexey Kovyazin a...@ib-aid.com [firebird-support] wrote: > > longest chain of versions here). > > If you will see a long chain of versions, it means that you are updating > the same record while some other writeable transaction

Re: [firebird-support] UPDATE to same record causing heavy disk I/O

On Tue, Dec 22, 2015 at 2:17 PM, Caroline Beltran caroline.d.belt...@gmail.com [firebird-support] < firebird-support@yahoogroups.com> wrote: > > > Since I began using Firebird, I have kept my transactions (type > concurrency) very short and then call COMMIT immediately afterward. This > has

Re: [firebird-support] UPDATE to same record causing heavy disk I/O

Hi Ann, >Just curious, why do you say both "COMMIT" and "end transaction" - Commit ends the transaction. Yes you are right. I shouldn't have said "end transaction" but I will answer your question why. I use the IBPP library for C++ and you create a pointer to the transaction. Immediately

[firebird-support] UPDATE to same record causing heavy disk I/O

Since I began using Firebird, I have kept my transactions (type concurrency) very short and then call COMMIT immediately afterward. This has worked very well. I recently had the need to perform more complex processing and what I did was to keep everything short and modular. But I am now seeing

Re: [firebird-support] UPDATE to same record causing heavy disk I/O

On Tue, Dec 22, 2015 at 2:17 PM, Caroline Beltran caroline.d.belt...@gmail.com [firebird-support] < firebird-support@yahoogroups.com> wrote: > > > Since I began using Firebird, I have kept my transactions (type > concurrency) very short and then call COMMIT immediately afterward. This > has