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

Your points are well taken.  The DataReader does present a unique
challenge because it is database specific.  We more often use datasets
despite the performance issues because we seem to find ourselves using
DataViews, DataRelations and some of the other features that are not
available with DataSets.  Where we have used DataReaders, we have been
forced to code to the underlying provider, unfortunately.  You would
need some sort of gymnastics to code the IDataReader generically, since
I believe it is set up as inherit only.  That's a topic for someone more
versed in this type of thing than me!

As a software development house, you have issues that we probably don't
consider.  I would imagine you are supporting different databases
simultaneously which is something we generally would not see as a
corporate IS department.  We look at a provider or database change as
something pretty rare, so a little work is no big deal.  I was not
thinking from your perspective, thanks for sharing your point of view.

Jim



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Wednesday, November 17, 2004 11:15 AM
To: Midrange Systems Technical Discussion
Subject: RE: Where can I get the New DB2 .NET provider?

>...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.)
 

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.