From: <ch...@co...> - 2004-04-27 21:14:41
|
In the database project that I've previously mention I had to write a persistance layer that wraps the Firebird.NET provider. The reason is that I can write to my persistance layer for both Firebird and possibly SQLServer and other DB's. A situation could arise whereby data could be obtained from disparate databases. The problem is that SQLServer provider supports ConnectionTimeout and the Firebird provider throws an exception. My request is that ConnectionTimeout rather than throw a runtime exeception to return 0 and use an Assert instead. Once again I modified the provider to return 0 causing no behavioral changes to the provider but now my layer can work polymorphically. Thanks, Chris > > The question is how to use a 16-byte GUID in Firebird when the system > > itself doesn't. In the database that I'm designing with Firebird I > > decided to reserve CHAR(16) for GUID only. If I have a need for a > > 16-byte character representation then I'll use either VARCHAR(16) or > > CHAR(17). In the CHAR(17) case I'm anticipating the front end to limit user > > input. > > A column of "char(16) character set octets" should in theory hold > a binary GUID. > > But it is a field of research, whether all layers involved will gladly > handle bytes of zero in this. It's worth a try. > > A middle ground between binary and textual GUIDs would be to use base64 > encoded binary GUIDs, requiring 22 bytes. > > Regards, > Peter Jacobi > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek > For a limited time only, get FREE Ground shipping on all orders of $35 > or more. Hurry up and shop folks, this offer expires April 30th! > http://www.thinkgeek.com/freeshipping/?cpg=12297 > _______________________________________________ > Firebird-net-provider mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-net-provider |
From:
<car...@te...> - 2004-04-28 17:02:57
|
Hello: >In the database project that I've previously mention I had to write a persistance layer that wraps the Firebird.NET provider. The reason is that I can write to my persistance layer for both Firebird and possibly SQLServer and other DB's. A situation could arise whereby data could be obtained from disparate databases. > >The problem is that SQLServer provider supports ConnectionTimeout and the Firebird provider throws an exception. My request is that ConnectionTimeout rather than throw a runtime exeception to return 0 and use an Assert instead. > >Once again I modified the provider to return 0 causing no behavioral changes to the provider but now my layer can work polymorphically. > Do you mean FbCommand.CommandTimeout ?? I'm not going to change that, at least for now, in my opinion that will give the false impression that it's supported and that it works, and it fact if you are going to use the CommandTimeout property probably you will be trying to call Cancel that will raise an NotSupported exception as well. I think the best for you will be to handle the NotSupported exception (other providers may throw it too) Opinions ?? -- Best regards Carlos Guzmán Álvarez Vigo-Spain |
From: Mike S. <mi...@mi...> - 2004-04-29 09:04:59
|
>> 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. Carlos Guzmán Álvarez wrote: > Hello: > >> In the database project that I've previously mention I had to write a >> persistance layer that wraps the Firebird.NET provider. The reason >> is that I can write to my persistance layer for both Firebird and >> possibly SQLServer and other DB's. A situation could arise whereby >> data could be obtained from disparate databases. >> >> The problem is that SQLServer provider supports ConnectionTimeout and >> the Firebird provider throws an exception. My request is that >> ConnectionTimeout rather than throw a runtime exeception to return 0 >> and use an Assert instead. >> >> Once again I modified the provider to return 0 causing no behavioral >> changes to the provider but now my layer can work polymorphically. >> > Do you mean FbCommand.CommandTimeout ?? I'm not going to change that, > at least for now, in my opinion that will give the false impression that > it's supported and that it works, and it fact if you are going to use > the CommandTimeout property probably you will be trying to call Cancel > that will raise an NotSupported exception as well. > > I think the best for you will be to handle the NotSupported exception > (other providers may throw it too) > > > Opinions ?? > > > > -- > Best regards > > Carlos Guzmán Álvarez > Vigo-Spain > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle > 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Firebird-net-provider mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-net-provider > > > |
From:
<car...@te...> - 2004-04-29 09:30:58
|
Hello: > 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. Reviewing the .NET 1.1 documentation we can see that: * SqlClient, Odbc and OleDb providers has CommandTimeout, none of them throws exception * OracleClient doesn't have CommandTimeout property as public, it will be accesible making explicit usage of the IDbCommand interface: ((IDbCommand)oracommand).CommandTimeout = 10; Making that doesn't throw exception. That from the Microsft providers, from the opensource ones for other RDBMS, there are at least one that throws exception. I think that probably the best will be to make the same as the OracleClient provider. Opinions ?? -- Best regards Carlos Guzmán álvarez Vigo-Spain |