Joost van der Sluis wrote:
- please send me some hints to configure a query as fast as possible --
read only and unidirectional. I will open the query, read everything and
close it.
Set ParseSQL to false. (This wil automatically set readonly to true) It
won't be unidirectional, but I made an unidirectional TSQLQuery once,
and coudn't measure any speed difference. The difference was to small.
And maybe you could tweak packetrecords. Set it to -1 so that all data
is fetched at once. That's faster if you really need all data
immediately. (Consumes more memory, though)
Thanks for the hints.
- what about RowsAffected?
You mean how many rows are affected by the last query you've run? I saw
request for that earlier.
But imho, you never need it. You always should know how many rows are
affected before you execute a query. It could be a debug-tool,
though.Maybe I could implement it. Maybe for one specific connection, or
maybe even in a general form.
This feature will be used in an opf framework to ensure that I didn't
have a conflict. Something like this:
update <list> where id = :id and updatecount = :lastupdatecount
If RowsAffected is 0 I have a conflict. I can use a select just before
the update but I will create an useless overhead, since the database
provides this information.
When you say implement it, you don't mean 2.2 I think. If so, would you
have a workaround to point out?
Thanks.
--
Joao Morais
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
