[fpc-pascal] SQLdb :: Commit, Rollback, etc.

[Marcos Douglas]

On Thu, Dec 1, 2011 at 6:17 AM, Ludo Brands <ludo.brands at free.fr> wrote:
>
>> I can't keep a transaction (server locked) all the time.
>>
>
> What database are you using that locks up the server when a transaction is
> started?

MS SQLServer 2008. Lock the registers, not the server... sorry.

> Oracle for example starts an transaction as soon as you send an executable
> SQL Statement. Opening a connection starts a transaction on the server.
> Therefor it is important to match this behavior on the client side and force
> the use of a TSQLTransaction. Using TADOConnection doesn't change this. ADO
> is just hiding it from you.

Ok, I can accept the TADOConnection can hiding a lot of things from
me, but I think it do open many transactions all the time.
Using SQLServer Profiler, I can see all SQL that are executing on the
server. So, I do not see BEGIN TRAN all the time, just when I call
BeginTrans.

> As long as you use a transaction level that is lower or equal to Read
> committed, a transaction is almost at no cost to a database server (other
> than access that doesn't support transactions or mysql that uses a different
> backend to support transactions).

I'm a tester of the new connector TMSSQLServer to SQLdb, by LacaK:
http://lazarus.freepascal.org/index.php/topic,15135.msg80922.html#msg80922

If the component Open a Query I see BEGIN TRAN and... the transaction
isn't closed!
Well, maybe there is a bug in the new class by I see the SQLdb
implementation and that class follow the design.

What I know is: "if a transaction is open, it's should be closed as
fast you can"... but if you right, the phrase should be " "if a
transaction is open, it's should be closed as fast you can, IF you
update something". Is that correct to you?

> In a client server application, datasets are local copies of (a part of) the
> database and should be short lived for tables that are updated regularly.
> Re-opening (re-fetching) data from such tables after a commit or rollback is
> almost a must to avoid the client working with old/wrong data. If you have
> datasets linked to "low or no update" tables, attach them to a different
> connection.

Ok, but I shoud be the controller of my DataSets, shouldn't it?
If, eg., I use RAD, how can I controller the DataSets that are using
for the users in DBGrid or something, if all DataSets will be closed
if he update something (that need a transaction)?

Marcos Douglas