Re: [Firebird-net-provider] Please remove exception in ConnectionTimeout

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

Hello:

>I agree with Mike and he express it much better than I did.  While I appreciate the technology of the provider -- *compatiblity* -- it most important factor for Firebird adoption.  In fact both Mono and DotGnu has both made compatibility with Microsoft.NET behavior its most paramount feature -- and for a good reason -- migration to Linux.
>
>I worked as a member of the Microsoft.NET/CLR team (Interop) and I can tell you Microsoft is formatible with their marketing strategy.  If you want Firebird to be adopted you should do everything in your power to be behaviorially compatible with the SqlServer provider such that adoption and migration is as seemless as possible.
>
I know that ;) and that is the reason the provider has named parameters 
with the
same sintax as SqlServer, stored procedure execution using only the sp 
name as
in SqlServer,  implicit transaction support and batch querys (that for 
now are
only in ExecuteReader)

>This is why I think you should also adopt my Guid request as many shop will be reluctant to use Firebird just on this *resolvable* the issue of compatibility.
>
I'm thinking on it, but was is needed for this is not only to modify the 
GdsReader/GdsWriter
implementation (XdrStream in 1.6), it's needed to define a new type in 
FbDbType enum
(and DbDatatype), implement the FbDataReader.GetGuid() ...

>However you do *not* need to throw an exception for ConnectionTimeout and Cancel because they do nothing to affect the mainline codepath.  They are stubs.  You can do an Assert (in the debug build) to notify the developer. 
>
The assemblys are released without the DEBUG define and with use the 
/debug switch
for emit the debug information.

In my opinion ( maybe i'm worng ) the exception is needed as soon as
it's not supported, the other option is to make the same as MS does
in the OracleClient provider with the CommandTimeout property.

I don't have problem on remove the exception, but without it people
is going to ask why it's not working, i'm sure about this and
i want to avoid it ;)

>Remember the Firebird .NET provider is not a closed source binary delivery it is an open source delivery with excellent documenation.  The fact that they are stub merely be placed in the documentation.
>
I know ;) and all suggestions and ideas for the .NET provider 
development are more
than wellcome




--
Best regards

Carlos Guzmán Álvarez
Vigo-Spain