Michael Van Canneyt wrote:
Well, you always need a transaction. Without a transaction, Postgres
will do nothing, ever.
I assume you are used to the fact that postgres automatically creates an
transaction for you. With Sqldb you have to do this yourself.
Please excuse me for threading onto a fairly old message. In the
specific case of PostgreSQL, if I use SELECT * FROM pg_stat_activity
to examine backend state I can see that a Lazarus TSQLQuery, i.e. that
has to have an associated transaction object, is explicitly marked as
being in a transaction, while other methods of access (Delphi+BDE,
PGAdmin3) are not.
This is one of the things we must still address: close the transaction
after
the data has been fetched. (or rather: keep data available in case the
transaction is closed)
I've not had a chance to investigate exactly what the backend thinks
Delphi etc. is doing, but long-lived connections caused in particular by
db-aware components could be bad news when it comes to server pooling,
failover and so on. Long-lived transactions definitely will be.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
