Re: Which database support?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Joe,

ADO is likely the better way to go, although ODBC is a close second. DAO
is OK, but *only* if the target database is based on the MSFT Jet Engine
(e.g. MS Access database, although MS Access is not a requirement, just the
Jet runtime)

ADO is built on OLEDB; Both are based on a set of interfaces defined by
Microsoft, so don't expect to see any provider specific capabilities
available in either. ADO, when compared to OLEDB, provides a lot of
features that can cut the development time by a factor of 10 or better.
Performance is comparable, especially when accessing a database over a LAN.
The ADO typelib, with the #import directive, provides a good set of
smartpointer classes and exception handling wrapper functions - and that has
a very positive impact on application robustness as well development time.
The documentation for ADO is quite good - albeit mostly written for the VB
programmer. Documentation for OLEDB is pathetically inadequate.

ODBC is ODBC - it has been around for a long time. MFC has good support for
connections and recordsets, but little else; ODBC has a lot of capabilities
and is a decent performer when programmed at the API, but is a bit tedious
(falling somewhere between ADO and OLEDB in this regard). Documentation for
the ODBC is good compared to OLEDB, and is comparable to that of ADO.

OLEDB and ODBC drivers exists for the popular databases - SqlServer, Jet,
Oracle, MySql, etc, etc... ADO will work for any database technology that
provides an OLEDB implementation.

regards
roy fine




"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:dnptc1puootpg9ibkrqe3epqg148ecrvgf@xxxxxxxxxx
> I don't do databases much (well, the last database work I did was about
eight years ago).
> But one of my clients needs to understand which of the many buzz-acronyms
should be used
> for database work. DAO has apparently been deprecated in VS7, which leaves
ADO, ODBC and
> OLEDB as options. To me these are largely meaningless terms, but if anyone
has a
> suggestion I can pass on as to which way new development should go, I'd
appreciate it.
> joe
>
> Joseph M. Newcomer [MVP]
> email: newcomer@xxxxxxxxxxxx
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


.

Relevant Pages

  • Re: Cannot display ODBC login prompt - want to connect without DSN
    ... ODBC was superseded thirteen years ago by OleDb: ... In this particular case, my program will conect to an Oracle database, but ... There does not seem to be a .NET provider for MS Access, ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: ADO Connection problem when not logged in as an Admin
    ... I never said that there was a difference between ODBC ADO and OLEDB ADO. ... Provider for ODBC) that can make the connection between ADO and an ODBC ...
    (microsoft.public.access.modulesdaovba)
  • Re: ADO connection with VBS to locally stored MS-Access database
    ... Even using of the OLEDB Jet provider is better, I do not see any confusion ... You could use ODBC or OLEDB syntax but in this case ADO will using ... > I am trying to connect to a local Access database via ADO and VB Script. ...
    (microsoft.public.data.ado)
  • Re: Word 2000/2002 - Proper Mail Merge steps for ODBC?
    ... > I don't get the "Database has been placed in a state by ... Access runs the query and will prompt for any ... > my ODBC entry and click the "Configure" button, ... >>using OLEDB, it uses a more exclusive mode than it really ...
    (microsoft.public.word.mailmerge.fields)
  • RE: C# and ADO vs. ADO.NET
    ... The OleDb* objects, for instance OleDbConnection, OleDbCommand, etc. are designed to work with ANY database that you can provide an OLEDB connection string for basically, for instance Access, Sybase, ... If you want to be even more generic, you can use the Odbc* objects - these go through the ODBC and OLEDB layers, so expect them to be slowest, but can access any type of database that supports ODBC. ...
    (microsoft.public.dotnet.languages.csharp)