Re: Supporting a variety of database types in an app?
- From: "Ralph" <nt_consulting64@xxxxxxxxx>
- Date: Fri, 2 Mar 2007 09:19:18 -0600
"tcruise" <u32170@uwe> wrote in message news:6e8e0f370bf11@xxxxxx
I have a VB6 application that currently allows the user to create andaccess
multiple Access databases (each database is for a different project), viaan
DSN-less ADO connection.New
Users can create a new database or access an existing database. Once a
database has been created/accessed, it appers in a list of available
databases that can be selected from a drop-down list in the Logon dialog.
databases are created by specifying a database name and the workingdirectory
for the new database (a template .mdb file is copied to the specifiedof
location and renamed).
To locate/select an existing database, the user navigates to the location
the .mdb file.database.
The path/filename of each database is stored in a table in a master
The connection parameters used to connect to Access databases are:use
DBQ: Path/filename of the .mdb file.
DEFAULTDIR: Path specified in DBQ (no filename).
DRIVER: {Microsoft Access Driver (*.mdb)}
FIL: {MS Access}
MAXBUFFERSIZE: 8192
I want to add the ability to create and access MS SQL databases. I could
the database filename extension (.mdb OR .mdf) to identify which type ofparameters
database the user has selected, and build the correct connection
on-the-fly (using a set of default values for each db type), depending ondatabase
which type of database the user has selected.
Is this the best way to accomplish support for more than one type of
in an application?scheme.
I'd especially like to hear from anyone who has implemented a similar
This is a topic far wider in scope and complexity than you might initially
realize. And therefore there isn't any single 'best way'. Nor is it a topic
easily answered in this media.
It is possible to create a 'generic' ADO scenario using one or two common
providers (say OLE DB over ODBC) that will work with multiple data sources.
After all, that is essentially what ADO was designed for. But eventually you
will run into 'database' specific issues (wildcards in SQL, date/time
formats, authenication/authorizing, datatypes, etc.) and performance
problems.
The same goes with trying to determine what kind of datasource a user might
be selecting just from the name (or in the case of Vista, from just its
'location'). While local file-based datasources are easier to detect, I
think you will find that some additional user interaction and plain-ole
trial 'n error is in your future.
The first step to maintaining your sanity, is to back up and refactor your
application to support a n-tier architecture. Employ VB's version of
polymorphism by substituting your current data access scheme with
Interfaces. So as to more efficiently handle the database-specific nuances
that are sure to arrive.
hth
-ralph
.
- Follow-Ups:
- Re: Supporting a variety of database types in an app?
- From: tcruise via VBMonster.com
- Re: Supporting a variety of database types in an app?
- References:
- Supporting a variety of database types in an app?
- From: tcruise
- Supporting a variety of database types in an app?
- Prev by Date: Supporting a variety of database types in an app?
- Next by Date: Re: Storing Images in an Oracle Database
- Previous by thread: Supporting a variety of database types in an app?
- Next by thread: Re: Supporting a variety of database types in an app?
- Index(es):
Relevant Pages
|