Platform ADO/DAO/ODBC/OLEDB?

Platform ADO/DAO/ODBC/OLEDB?

Post by Martin Richte » Thu, 23 Sep 1999 04:00:00



I have to solve the following problem:

1. Read and select data from various data sources. Normaly via a simple
select from a complete table, might be manipulated by a simple where
statement. The data are customer data in most cases (incl. address, phone
no. etc.)
2. I have to determine the datasource and the primary keys, so that it is
possible to reconnect to the individual database and to select the
individual record that was used under step 1.
3. So later the program should select an specific record, offer some dialogs
to make modifications and update the specific record.

The use should never be aware that the data is selected from various
datasources. An administrator should be able to perform step 1.

The datasources might differ from simple Access tables, over various
SQL-Engines (Oracle,MS,Pervasive). So think of every system were large
customer data might be stored.

So from the various access methods, what should I use ADO/DAO/ODBC/OLEDB?

The program will be developed in MSVC++ 6.0.

I am close at to the point to choose ODBC, because of its wide support and
its good tested interface.
Also ADO/DAO has more feautures and a better command structure.
And there is the brand new OLEDB, with a very open interface with its COM
structure.

Martin Richter
Grutzeck-Software GmbH
Hanau, Germany

Web: http://www.grutzeck.de

 
 
 

Platform ADO/DAO/ODBC/OLEDB?

Post by Mark Richard » Thu, 23 Sep 1999 04:00:00


Your decision becomes much simpler once you realize that ADO/DAO and
ODBC/OLEDB are two different levels.  Think of ADO/DAO as high level
interfaces, ODBC/OLEDB as drivers.  You do not want to access
databases at the driver level!

I would start with a VB prototype, in which you can quickly see for
yourself if ADO or DAO is the better interface for your needs (and in
which you can easily learn either without getting bogged down by the
details of using COM objects in C++).  ADO is the newer one, has been
written with ease of use for common programming tasks in mind (it
offers some good shortcuts to common operations), and is the interface
being recommended and improved by microsoft.  ADO supports connecting
to a database through either ODBC or OLEDB.

As far as which driver should you use to connect to the database, ODBC
or OLEDB, it is a question of: which driver is available, which has
the most acceptable performance for your application, which gives you
access to what you want!  It will not be hard to structure your
application so that the connect strings are stored rather than
hardcoded, in which case you really don't care which driver is used
and you can change your mind at any time.  Note that there is a
general OLEDB driver (I should say provider like the documentation
says) that can use an ODBC data source, and vice versa, when the
structure of the underlying database allows it (OLEDB is meant to
support a wider class of databases than ODBC, including hierachical
data).

Hope this helps you narrow down your questions when you search msdn,
msdn online, and your other resources.

Mark


> I have to solve the following problem:

> 1. Read and select data from various data sources. Normaly via a
simple
> select from a complete table, might be manipulated by a simple where
> statement. The data are customer data in most cases (incl. address,
phone
> no. etc.)
> 2. I have to determine the datasource and the primary keys, so that
it is
> possible to reconnect to the individual database and to select the
> individual record that was used under step 1.
> 3. So later the program should select an specific record, offer some
dialogs
> to make modifications and update the specific record.

> The use should never be aware that the data is selected from various
> datasources. An administrator should be able to perform step 1.

> The datasources might differ from simple Access tables, over various
> SQL-Engines (Oracle,MS,Pervasive). So think of every system were
large
> customer data might be stored.

> So from the various access methods, what should I use
ADO/DAO/ODBC/OLEDB?

> The program will be developed in MSVC++ 6.0.

> I am close at to the point to choose ODBC, because of its wide
support and
> its good tested interface.
> Also ADO/DAO has more feautures and a better command structure.
> And there is the brand new OLEDB, with a very open interface with
its COM
> structure.

> Martin Richter
> Grutzeck-Software GmbH
> Hanau, Germany

> Web: http://www.grutzeck.de


 
 
 

Platform ADO/DAO/ODBC/OLEDB?

Post by morris_mi.. » Sat, 02 Oct 1999 04:00:00




Quote:>.....ADO supports connecting
> to a database through either ODBC or OLEDB.

Well, strictly speaking, you are either using the OLEDB native provider
specific to the database, or using the OLEDB native provider for the
ODBC driver interface, with an associated performance reduction.
Quote:

> As far as which driver should you use to connect to the database, ODBC
> or OLEDB, it is a question of: which driver is available, which has
> the most acceptable performance for your application, which gives you
> access to what you want...

Agreed. Although there were initially more data providers that were
only exposed through ODBC because it is an older technology, most of
the major (relational) data providers have native OLEDB providers, and
several non relational ones. Can anyone suggest a good reason to use
ODBC when there is a native provider available?
--
Mike

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

1. SQL SRVR 7 and ACCESS'97 : ADO,DAO,ODBC,OLEDB

HI:
I need to attach an existing ACCESS'97 front-end to a new
SQL SRVR 7
backend using WIN 2000 Pro Edition on all desktops and
servers;
Currently all tables are resident within ACCESS'97, these
tables will be
migrated/upsized to SQL SRVR.
My reading leaves me confused on the following points:
a) can i even use ADO (instead of my current DAO code) and
connect to
SQL SRVR 7 on a network ?
b) if i can connect using ADO, does it "do me any good" as
opposed to
my current DAO "connection" (sic)
c) can the connection mode be OLEDB provider or must it be
ODBC
d) if i am limited to ODBC, can i expect any performance
increase over
my current ODBC connections
e) given the answers to a) thru d), can i take any real
advantage of the
server-side database performance features of SQL SRVR ?
I appreciate any advice on these items.
thank you
VernDeGeus

2. Strange Problem

3. SQL SRVR 7, ACCESS'97 ADO,DAO,ODBC,OLEDB

4. .HTACCESS in FMPRO???

5. SQL SRVR 7, ACCESS'97, ADO,DAO,ODBC,OLEDB

6. FS: Interbase Workgroup Server $200

7. Difference b/w ADO/ODBC/OleDB and dao

8. can not use Query Analyzer

9. difference b/w ADO/OleDB/ODBC and DAO

10. ADO - OLEDB Provide for ODBC - ANSI ODBC Driver ( ANSI Data Source )

11. DAO/ADO/OLEDB which to use these days?

12. using dao, oledb, ado

13. Confusion ADO/DAO/OLEDB