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

[<ch...@co...>]

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.

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.

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 connection string idea is flawed because you can create a DbConnection without the connection string and call ConnectionTimeout before settting the connection string...

FbConnection conn = new FbConnection();
conn.ConnectionTimeout = 100;  // Bad: throw or not to throw?

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.


Thanks,
ChrisWa.

>  >> I think the best for you will be to handle the NotSupported exception
> (other providers may throw it too)  <<
> 
> This is the important point: what do other providers do? If none of them 
> throw an exception, then the Firebird provider shouldn't. If some do and 
> some don't, then it's a matter of opinion, but if the most common ones, 
> e.g. SQL Server, don't then probably FB shouldn't either.
> 
> I agree with Carlos that it *should* throw an exception, but no provider 
> is an island so to speak, and we must think about compatibility with 
> other providers.
> 
> Can't you add an option in the connection string to switch off 
> exceptions in this one case? That way, anyone wanting to switch 
> providers just has to add one line to the connection string, and it'll 
> work like some other providers.
> 
> Cheers,
> 
> Mike.
>