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.