firebird-net-provider

RE: [Firebird-net-provider] FBCommand.ExecuteReader and Transactions

[Leyne, S. <Se...@Br...>]

Carlos,

> > Is there a reason for this different behaviour ?
>=20
> Well, i don't know how transactions work with Sql Server 2000, but in=20
> Firebird you a need always a trasaction for allow command execution (=20
> stored procs, select, insert, delete, update ).

While true, a number of data drivers also support implicit-start
transaction connections.


Sean

Re: [Firebird-net-provider] FBCommand.ExecuteReader and Transactions

[Carlos G. A. <car...@te...>]

Hello:

> While true, a number of data drivers also support implicit-start
> transaction connections.

Yes, i know, but i think there no easy solution for this and mantain 
compatibility with ADO.NET ( or i can't find one :) ), i have some 
thinks in mind but none of them is really good for me  :)


Ideas are welcome.



-- 
Best regards

Carlos Guzmán Álvarez
Vigo-Spain

"No tengo dones especiales.Sólo soy apasionadamente curioso"
Albert Einstein, científico.

Re: [Firebird-net-provider] FBCommand.ExecuteReader and Transactions

[Pavol S. <st...@st...>]

hallo,

i want to say, that adding autostart transaction support is not hard to
implement... Simple add there new constructor for FbCommand or other
components without transaction and in that start default transaction... in
close method rollback or commit...

but this is against carlos philosophy... he dont want bind things together
and want as few relations as possible between connection, trancation and
command...
And i like his aproach, im doing high performance apps, so i wand direct
control about this...
This is my opinion and my be im wrong, but i was speaking with carlos about
some time ago and i observed his code a lot... Hi knows that its not hard to
do that, but i think hi dont want do that :)

carlos if im wrong sorry...

p.

Re: [Firebird-net-provider] FBCommand.ExecuteReader and Transactions

[Carlos G. A. <car...@te...>]

Hello:

> i want to say, that adding autostart transaction support is not hard to
> implement... Simple add there new constructor for FbCommand or other
> components without transaction and in that start default transaction... in
> close method rollback or commit...

Well, my first idea was to start a new transaction in 
FbStatement.Prepare method if the command don't have a transaction yet 
and it's a select ( probably by check if CommandText start with SELECT ) 
and rollback it in Close method, but this can have problems, for example 
lots of open transactions if you left the connection to close the 
commands .....

> but this is against carlos philosophy... he dont want bind things together
> and want as few relations as possible between connection, trancation and
> command...
> And i like his aproach, im doing high performance apps, so i wand direct
> control about this...
> This is my opinion and my be im wrong, but i was speaking with carlos about
> some time ago and i observed his code a lot... Hi knows that its not hard to
> do that, but i think hi dont want do that :)

Huummm you are right, at this moment if you want to make an application 
that can work with, for example, Firebird and MS Sql Server ( or any 
other ) as database server, you can make a data access layer having in 
mind that you need to start a transaction always before executing a 
command, with this you can solve the problem, this is the reason why i 
think this is not a great problem ( i will try to make a test with MSDE 
or an evaluation version of Sql Server 2000 for being sure about it ).

> carlos if im wrong sorry...

No problem :) , i want to hear opinions about this :)



-- 
Best regards

Carlos Guzmán Álvarez
Vigo-Spain

Re: [Firebird-net-provider] FBCommand.ExecuteReader and Transactions

[Pavol S. <st...@st...>]

hi,

this is really interesting problem... Ideology of your provider and for
example MS provider or Ado itself is little, but in main things different...
and of course your provider is still not finished. Im affraid that you do it
in way how ib or now fb API works and did not check how other common
providers work... anyway i like your point of view and dont like to add
there new features becouse each new feature is performance hit and makes
code dirty... It like with firebird server. It have now lot of new features
but its 20% slower :(

i see that you want to make your provider as near to ADO.NET as possibe..
Its great idea. But i think, that you have to make there new layer of
codebase for example ADOFbConnection and so... Becouse there is still lot of
work in base layer... You can have to have one connection for one command
(big problem), problems with cleaning resources when i forgot dispose
something... And trying to force it to be ADO compatible will not work...

So simple as i wrote there are constructor where you assign transactions, in
this step when assigned transaction is null or not specified you create and
start new one... and when you call close or dispose you will commit or
rollback... In this case will be transaction closed by command not
connection, and is not created for each statement, so you can call prepare
many times... And oposite there is one transaction which will be closed as
command is closed (transaction is private in this case) so there will not be
problem with lot of transaction to be closed by connection...
Best way i see is create inherited class ADOFbCommand with new overloaded
constructor and new close and dispose.

Or you can replace this:
if (Transaction == null)

throw new InvalidOperationException("Command must have a valid
Transaction.");

in executeNoQuery, Scalar, Reader by



if (Transaction == null)

    Transaction = Connection.BeginTransaction();

// ofcourse you know that there is connection


you can put this only in ExecuteReader an can set behavior to
CloseConnection and there will be no problems with closing :)

As i wrote this, why near all classes are sealed???
There is lot of possibilities how to do that. Question whis is best :)

BUT PLEASE DO NOT MIX IT IN WORKING CODE, until all other required features
are implemented... i fell that it will bring lot of problems to try it make
MS compatible and will corrupt working code...

AND I WANT TO THANK YOU FOR THIS PROVIDER ITS GREAT, ITS PERFECT, ITS BEST
:) I use it every day and for now i did not find any problem which cannot be
done by this or any bug you did not correct fast...

p.

Re: [Firebird-net-provider] FBCommand.ExecuteReader and Transactions

[<car...@te...>]

Hello:

> this is really interesting problem... Ideology of your provider and for
> example MS provider or Ado itself is little, but in main things different...
> and of course your provider is still not finished. Im affraid that you do it
> in way how ib or now fb API works and did not check how other common
> providers work... 

Well i see some things with the MS ODBC .NET data provider ( using 
IBPhoenix ODBC driver ), but i think this is a problem on how servers 
manage some things, transactions is an example, named parameters or ? 
placeholder can be other, etc..., and this things can be easy or not, 
good or not, to do.

I'm thinking in write a data access layer and commit it to the CVS, Any 
thoughts ???

> anyway i like your point of view and dont like to add
> there new features becouse each new feature is performance hit and makes
> code dirty... It like with firebird server.

:)

> It have now lot of new features
> but its 20% slower :(

Which features ??

> i see that you want to make your provider as near to ADO.NET as possibe..
> Its great idea. But i think, that you have to make there new layer of
> codebase for example ADOFbConnection and so... Becouse there is still lot of
> work in base layer... You can have to have one connection for one command
> (big problem), problems with cleaning resources when i forgot dispose
> something... And trying to force it to be ADO compatible will not work...
> 
> So simple as i wrote there are constructor where you assign transactions, in
> this step when assigned transaction is null or not specified you create and
> start new one... and when you call close or dispose you will commit or
> rollback... In this case will be transaction closed by command not
> connection, and is not created for each statement, so you can call prepare
> many times... And oposite there is one transaction which will be closed as
> command is closed (transaction is private in this case) so there will not be
> problem with lot of transaction to be closed by connection...
> Best way i see is create inherited class ADOFbCommand with new overloaded
> constructor and new close and dispose.
> 
> Or you can replace this:
> if (Transaction == null)
> 
> throw new InvalidOperationException("Command must have a valid
> Transaction.");
> 
> in executeNoQuery, Scalar, Reader by
> 
> 
> 
> if (Transaction == null)
> 
>     Transaction = Connection.BeginTransaction();
> 
> // ofcourse you know that there is connection
> 
> 
> you can put this only in ExecuteReader an can set behavior to
> CloseConnection and there will be no problems with closing :)

I know that there are some ways to do this, but i see this only for 
select commands, we need to think for example that DbDataAdapter make 
calls to ExecuteReader when it exec the insert, update or delete 
commands of FbDataAdapter, and i think that for update operations is 
better to make explicit transactions.

> As i wrote this, why near all classes are sealed???
> There is lot of possibilities how to do that. Question whis is best :)

Because the same classses of other providers are sealed :)

> BUT PLEASE DO NOT MIX IT IN WORKING CODE, until all other required features
> are implemented... i fell that it will bring lot of problems to try it make
> MS compatible and will corrupt working code...

I'm not going to do that


> AND I WANT TO THANK YOU FOR THIS PROVIDER ITS GREAT, ITS PERFECT, ITS BEST
> :) I use it every day and for now i did not find any problem which cannot be
> done by this or any bug you did not correct fast...

Thanks very much :)




-- 
Best regards

Carlos Guzmán Álvarez
Vigo-Spain

"No tengo dones especiales.Sólo soy apasionadamente curioso"
Albert Einstein, científico.

Re: [Firebird-net-provider] FBCommand.ExecuteReader and Transactions

[Carlos G. A. <car...@te...>]

Hello:

> Huummm you are right, at this moment if you want to make an application 
> that can work with, for example, Firebird and MS Sql Server ( or any 
> other ) as database server, you can make a data access layer having in 
> mind that you need to start a transaction always before executing a 
> command, with this you can solve the problem, this is the reason why i 
> think this is not a great problem ( i will try to make a test with MSDE 
> or an evaluation version of Sql Server 2000 for being sure about it ).


I make some test with an evaluation version of MS SQL Server 2000 and 
seems that i'm right, for the test i use the AS3AP Benchmark suite that 
can be found at Firebird project CVS.





-- 
Best regards

Carlos Guzmán Álvarez
Vigo-Spain

"No tengo dones especiales.Sólo soy apasionadamente curioso"
Albert Einstein, científico.