[Lazarus] What is a TSQLTransaction and why do I need one?

michael.vancanneyt at wisa.be michael.vancanneyt at wisa.be
Tue Nov 30 11:54:43 CET 2010

On Tue, 30 Nov 2010, Joost van der Sluis wrote:

> On Mon, 2010-11-29 at 17:57 +0100, michael.vancanneyt at wisa.be wrote:
>> On Mon, 29 Nov 2010, Joost van der Sluis wrote:
>>> On Wed, 2010-11-24 at 20:57 +0100, Michael Van Canneyt wrote:
>>>> On Wed, 24 Nov 2010, Alexsander Rosa wrote:
>>>>> But it is transparent to the libpq programmer; why it's not transparent with sqldb?
>>>> Correction: it can be transparant in libpq.
>>>> But we can make it so in SQLDB.
>>>> The SQLDB model is in fact modeled after Firebird.
>>>> Firebird offers more control over the transactions.
>>>> We did not want to take away this possibility, so we modeled sqldb on
>>>> the most powerful RDBMS. This adds some overhead for the others.
>>>> What we neglected to do is add what Martin added: offer a less intrusive
>>>> way for the programmer to use it (i.e. create a default transaction in the
>>>> background if none is specified, and close the transaction once the data
>>>> is read).
>>>> But we'll do that too, all in good time.
>>>> If someone is in a hurry, patches are definitely accepted.
>>> Problem is that I haven't found a good model for this. Martin's solution
>>> could be an idea, though.
>>> It could help if someone could sketch the typical wanted behavior from
>>> the transactions.
>> I sent an idea for an implementation in a reply to Alexsander Rosa.
>> basically:
>> TConnectionOption = (coAutoTransaction)
>> TConnectionOptions = set of TConnectionOption;
>> Property TSQLConnection.options = TConnectionOptions;
>> Procedure TSQLConnection.CreateDefaultTransaction;
>> If coAutoTransaction is set, and TSQLQuery does not have a TSQLTransaction
>> assigned, it creates one through TSQLConnection.CreateDefaultTransaction.
>> (It should be of type TSQLAutoTransaction, a simple descendent of
>> TSQLtransaction, so detection of 'default transaction' is simple)
>> Whenever a TSQLQuery statement is executed and the transaction of TSQLTransaction is
>> of type TSQLAutoTransaction, then it automatically commits (more flags can be introduced
>> for this).
> This doesn't change Alexsander problem, because there's still the same
> transaction. Only difference is that he doesn't have to place it on the
> form.

I thought that exactly this was his problem ? Namely, that he is forced to
use a transaction component.

> Besides that, I think that disabling the explicit transaction for
> Postgres can be done much easier.

Maybe, but that would be a postgres-only solution, which I don't think is good. 
I heavily oppose such a solution: SQLDB should behave the same on all databases.

My proposal would work on all platforms, and alleviates Alexsander's problem.


More information about the Lazarus mailing list