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.