Re: opening an Access 2000 DB using ODBC...
From: Ralph (msnews.20.nt_consulting32_at_spamgourmet.com)
Date: 11/27/04
- Next message: Stefanie: "Re: Run query using VB6 and DAO"
- Previous message: Gijs Beukenoot: "Re: Run query using VB6 and DAO"
- In reply to: Brad Pears: "Re: opening an Access 2000 DB using ODBC..."
- Next in thread: Brad Pears: "Re: opening an Access 2000 DB using ODBC..."
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 27 Nov 2004 08:30:44 -0600
"Brad Pears" <donotreply@notreal.com> wrote in message
news:O6Sm0Zz0EHA.1260@TK2MSFTNGP12.phx.gbl...
> What exactly does "DSN-less" mean? Is that the opening of a DB within your
> app directly as opposed to referenceing the DSN of say an ODBC driver and
> hence incurring another layer to go through before actually accessing your
> data?
>
> Am I to assume that a DSN less connection would be way faster and hence a
> better way to go?
>
> Brad
The link I gave you explains the difference between DNS/DNS-less
connections. As far as speed goes, I think one could assume that a DNS-less
connection would be a little 'faster' since you are adding an extra file
I/O. But connections are always expensive in terms of time, so I doubt you
would notice much difference on a modern box.
As an aside: Database connectivity has been (and likely will be) a changing
technology. The reason there are so many options available is because while
new technology becomes available, many other modes are still supported to
maintain backward compatibility. Also, just like everything else in
programming, there are various trade-offs with each one. When investigating
each option you need to step back and take look at the broader picture.
For example, DSN files allows your app to not have to know much about 'how'
a connection is made. Only a file name or 'alias' is needed. This makes it
easier in some ways to write your app and distribute it about. You could
even define different DSNs with different providers and possibly different
databases for some boxes. For example, you might create one DSN that looks
at test data and another that connects to production. But as long as the app
just looks for "MyDSN" the code in the app never needs to change. All of
this was more important in the days of networks dependant on 'logical'
drives and different providers, &etc., than perhaps today - but it is still
something to consider.
ODBC is only one method of providing a middle-tier between the database
engine and the application. Appreciate that there is always several layers
between the runtime code of an application and the database. Depending on
where you want to draw the lines - the layers look something like this...
Database (files/struct/) -> Database Engine -> Engine API <- Middle
Adaptor -> Client API <- Runtime Code
In the case of MSAccess using ODBC/ADO you have something like this.
Database (files/struct) = .mdb files
Database Engine = Jet
Engine API = Jet ODBC drivers
Middle Adaptor = ODBC OLEDB
Client API = ADO (ActiveX Data Object Library)
Runtime = VB
When you use DAO you can 'skip' the middle adaptor
Database (files/struct) = mdb files
Database Engine = Jet
Engine API = ODBCDirect
Client API = DAO
Runtime = VB
So this is a long way of saying 'Yes', using DAO is more efficient.
hth
-ralph
- Next message: Stefanie: "Re: Run query using VB6 and DAO"
- Previous message: Gijs Beukenoot: "Re: Run query using VB6 and DAO"
- In reply to: Brad Pears: "Re: opening an Access 2000 DB using ODBC..."
- Next in thread: Brad Pears: "Re: opening an Access 2000 DB using ODBC..."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
