RE: Where can I get the New DB2 .NET provider?

["Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>]

>...and I can switch between them by changing the using clauses.
>...nearly no application code changes... 

That's still a code change. I'd like to do it with a change in
web.config. 

I've seen the block before, and it has some nice features, but still
requires some code changes for a change in provider -- as you mention,
you need a copy of the data block for each provider (OLE/DB, SQL,
iSeries, Oracle, etc.) and you need to change the code in the consuming
function too. 

Take the ExecuteReader method, MS's returns an SqlDataReader object, I
imagine yours returns an iDB2DataReader object, how do you deal with
that in the consuming function? Granted, you could use the generic
DataSet object, but there are performance issues with that[1]. 

I'm looking at the fact that all these DataReaders, for example,
implement the IDataReader interface, so why not code to that interface.
Granted, you'll loose any provider-specific enhancements (for example,
packet size for SQLServer or JobName for the iSeries) but if you're
using them you've tied yourself to a provider anyway.

As far as I can tell (looking _very_ quickly) the only thing that would
need to be provider aware is the actual creation of the connection
object. I'd like to see a generic connection class factory that used
something like LoadAssembly and reflection to load and return a
provider-specific connection object w/o knowing anything about the
provider at compile time. 

Actually, I'd like to see a more robust implementation of connection
pooling, and I could hide the implementation details in the pool.

-Walden

[1] I don't know if "issues" is a fair term. The DataSet is fast, it's
just that a DataReader is fastER.

------------
Walden H Leverich III
President & CEO
Tech Software
(516) 627-3800 x11
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com 

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)