× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Sorry for the repost, I forgot to change the topic...

Walden,

>And if I replace the "new iDB2Connection(sCS)" part with a call to a
>class factory that returned whatever type of connection I needed, I may
>be able to work with provider-specific objects in a generic way.
>However, while I complied the above code to see if it was syntatically
>correct, I've _NOT_ tried to use it at all. I may have all sorts of
>problems actually trying to assign different connection objects to the
>generic interface.

This is very similar to what I had in mind.  Imagine a database file,
either in SQL Server, Oracle, or iSeries.  Naturally, I want to
encapsulate DB access to the file in a class.  Now, I need 3 different
approaches because of the 3 different .NET providers, but I want to hide
that detail from anyone using the class, so I was thinking that the
"encapsulating class" would actually be a wrapper of some sort:

callingClass => 
        wrapperClass 
        { looks in Config for DBAccess Type } => 
                OracleDB || iSeriesDB || SQLServerDB

Since these methods implement the same interface, I should be able to
issue commands and pass DataSets back and forth in the wrapper class. 
All the properties would be in the wrapperClass, who acts as an agent
for the DBAccess classes.  Now all of my calling code always uses the
same class for file access, and the implementation is masked inside the
standard "CRUD" methods.

It's just a thought I've been toying with, I certainly don't have it
crystallized yet.  Any input would be appreciated.

Joel
http://www.rpgnext.com

P.S.  My BP is supposed to be ordering the CA refresh for V5R3.  The
beta download has "expired", even though IBM still has a bunch of pages
dedicated to it...


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.