Lester Caine wrote:

>> 2.) Because of the cooperative GC on SS some queries could have to
>> handle the load to clean-up the garbage left by other transactions, so
>> in some cases a query would be slow than it would be if cooperative GC
>> was turned off.
> Now THAT is a possible. All the records were updated by populating TRANSACT_NO
> so there will be 100k+ duplicate records following the scan by the stored
> procedure. I do a backup and restore once everything has been tidied, so I
> would not notice that, but if FB2 is doing an in line tidy, that could explain
> the difference ? I did not just try running the query again so I'll try that.

THAT looks like it was the problem. I did a backup and restore before running
the query, and it's even faster than FB1.5. Since modifying that many records
would only ever be an engineering function I can safely ignore it :)

--
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php