At 09:41 PM 24/10/2007, you wrote:

>Helen,
>
>I'm familiar with TSQLConnection and its methods to handle
>transactions, but I don't see how should you it when populating a
>ClientDataset. To populate a ClientDataset I just "open" it. Then
>Delphi (dbexpress or whatever) opens the database connection (if it's
>not already open) fetches the data and populate my ClientDataset. Are
>you telling me that I should hook some code in the middle of this
>process to proper handle transactions?

Yes.

>Maybe if I set KeepConnection to False in TSQLConnection and let it
>drop the connection when there is no datasets active, could help?

That won't work. If you don't close the provider datasets and commit the transaction, you would be "out of the frying pan into the fire".

>I
>just worry about the speed penalty for connecting and disconnecting
>all the time.

Don't confuse a connection with a transaction. They are not the same thing. Transactions run within the context of a connection. The TSQLConnection happens to embed a single transaction - one and only one. This means that you can't run multiple concurrent transactions within a single connection context - a limitation of DBX, not of Firebird. But it doesn't mean you can just ignore that transaction. Make sure you commit it when you have got what you want from it. The same (embedded) transaction object will then be ended (and become uninteresting, as long as you do NOT allow CommitRetaining to be called) and will be available to wrap the next transaction you need.

I would want to take total charge of it and call StartTransaction each time I want to open a provider...

./heLen