>Still that won't account for a difference of 7s in processing time. I
>would expect to find that your "block" is trudging its way through a
>dataset, possibly forcing prepares where they're not needed, and destroying
>SQL objects each time the process completes.
>
>
>

Actually the difference is more like 10s !

In my 'block' I do create TQuery components etc at the start, connect
them to an existing / open connection and free them at the end. I am
not sure how stepping through a dataset that contains 6 records (in this
case), could be so much slower in this case. I am updating a number of
large tables.

Im not really sure what to look for here as the code block is large and
the pause occurs on the commit statement. I have tried just putting the
start / commit transaction around a single statement i.e.
MyQuery.ExecSQL and this adds about a second to the process !

This procedure is taking place within a thread. It has been performing
fine in the past but perhaps there is something I am doing wrong in
relation to threads?

>If you really are doing this process optimally, then on your figures I'd
>expect the first run-through to be slowish (say 5 secs, though I consider
>this at least 5X too long) and subsequent ones to be sub-second. The
>desktop-to-client-server mindshift isn't just about controlling transactions.
>
>
>

Yes 5s is at least 5x too long :) considering with autocommit it takes
0.4s. Why would the second pass through be faster? Are you reffering
to the fact that it will be prepared the second time through? In this
case it is only a fractionally faster, however I am freeing my
components at the end.

>You might well have a GC thread competing with your process. You wouldn't
>expect this on every run-through but could well expect it on the
>first. That also depends on what the previous run of the process did - if
>it performed a lot of updates and/or deletes then one instance of the
>process is going to cop the GC.
>
>
>

I thought about this but a backup and restore does not improve the
situation.

>If you are doing multiple operations using DML from application "for" loops
>then that will be a place to start.
>
>
>

Sorry Im not sure what you mean by this. Are you meaning specifically
'for' loops or just loops in general? Why?


Thanks for your time Helen :)

Rob