Re: String vs. Collection
- From: "boaz" <nospam@xxxxxxxxx>
- Date: Fri, 19 May 2006 16:18:29 -0700
I see... so basically, what you are saying is that depending on what
database I am connecting, the program will "switch" Class to match the
database.
"Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
news:Ps6dnW6zHpwiofPZRVn-tw@xxxxxxxxxxxxxxx
"boaz" <nospam@xxxxxxxxx> wrote in message
news:uM49CC4eGHA.3336@xxxxxxxxxxxxxxxxxxxxxxx
I don't see how "Implements" can work...against
"Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
news:m6udnS4gadCOmfPZRVn-iA@xxxxxxxxxxxxxxx
"boaz" <nospam@xxxxxxxxx> wrote in message
news:eGEZfr2eGHA.1856@xxxxxxxxxxxxxxxxxxxxxxx
I can see why you might want to avoid classes, but I still
think leavine the data in the recordset may be a better
option for you.
Another problem of mine is that the same program needs to be run
itdifferent databases. Sometimes it is connected to Access. Sometimes
Sometimesis
connected to SQL Server. Sometimes it is connected to Oracle.
theit
is DB2. and some others.
The data types in these database are all different from each other.
Sometimes they have something called a "Money" data type that crashes
recordset.
So... no more recordset... use all string...
My I suggest, in the true tradition of the "Graduate", One Word -
"Implements". <g>
Checkout Facade, Bridge, and Adaptor patterns.
-ralph
Well for starters, from a 100k view...
' CProjConfig
' a class that just inits itself on startup, reading ini, reg,
' command line, etc with project specific information
' database location, security, etc.
' IDB
' a generic connection class
Public Function adoConn() As ADO.Connection
Public Sub Init(ByRef cls As CProjConfig)
'
' Class COracle
Implements IDB
Private Function IDB_adoConn As ADO.Connection ...
Private Sub IDB_Init(ByRef cls As CProjConfig)
' Class CMSAccess
Implements IDB
Private Function IDB_adoConn As ADO.Connection ...
Private Sub IDB_Init(ByRef cls As CProjConfig)
' Class CSQLSvr
Implements IDB
Private Function IDB_adoConn As ADO.Connection ...
Private Sub IDB_Init(ByRef cls As CProjConfig)
Dim gcConfig As CProjConfig
Dim gcDB As IDB
Sub Main()
Set gcConfig = New CProjConfig: ' gcConfig.Init()
Select Case gcConfig.Database
Case "Oracle"
Set gcDB = New COracle: gcDB.Init(gcConfig)
Case "Access"
Set gcDB = New CMSAccess : gcDB.Init(gcConfig)
Case "SQL"
Set gcDB = New CSQLSvr: gcDB.Init(gcConfig)
End Select
' for the rest of the project whenever an ADO Connection is
' needed...
gcDB.adoConnection
...
End Sub
If you want you can easily replace the Select Case with a conditional
compile for specific releases. Other objects would fit this pattern as
well..
ICustomer, CCustomerOra, CCustomerSQL, CCustomerMSA
Private cCust As ICustomer
#If MYDB = "Oracle" Then
Set cCust = New CCustomerOra
...
Handling different data types such as "Money" and "Currency" would be
managed in a similar fashion - create some kind of "CDollar" class and let
it access either one as needed.
Hey, but don't get me wrong, if you find it easier to manipulate strings,
then so be it.
.
- Follow-Ups:
- Re: String vs. Collection
- From: Ralph
- Re: String vs. Collection
- References:
- String vs. Collection
- From: boaz
- Re: String vs. Collection
- From: Bob O`Bob
- Re: String vs. Collection
- From: boaz
- Re: String vs. Collection
- From: Jan Hyde
- Re: String vs. Collection
- From: boaz
- Re: String vs. Collection
- From: Jan Hyde
- Re: String vs. Collection
- From: boaz
- Re: String vs. Collection
- From: Ralph
- Re: String vs. Collection
- From: boaz
- Re: String vs. Collection
- From: Ralph
- String vs. Collection
- Prev by Date: Re: String vs. Collection
- Next by Date: A working program that is "Not Responding"!
- Previous by thread: Re: String vs. Collection
- Next by thread: Re: String vs. Collection
- Index(es):
Relevant Pages
|