![]() |
#1
|
|||
|
|||
Database programming in C++
Hi,
I am looking for help about the different database technologies that can be used on Visual C++. I would appreciate if anyone could give me a link or something to understand the real differences between DAO, ODBC, ADO and OLE DB. I have used ODBC, but as far as I know, ADO is the newest technology that has been developed. What about compatibility? On mySQL, I think ODBC is the only one that is officially supported. Any comments about this are welcome. Thanks in advance. |
#2
|
|||
|
|||
ODBC (Open Database Connectivity) is a database connectivity standard, used to normalize access to a variety of DBMS systems through a common API. It isn't generally used directly to get/set data, though, since its API is procedural (and thus a pain to use with RAD/object-oriented tools/languages; but if you're still using plain old C, hey, have at it). Object-oriented data models such as DAO or RDO are almost always used on top of ODBC when working in C++.
DAO (Data Access Object) is an old object model based on the Jet database engine that acts as an object-oriented proxy between code and the ODBC API. Lots of overhead because the resultset has to be converted to Jet format. Primitive, slow, etc. RDO (Remote Data Objects) is simply a COM wrapper for the ODBC API. Just exposes ODBC functionality through COM interfaces, nothing to it. ODBCDirect is a sort of DAO working mode; when enabled, it uses RDO and ODBC instead of Jet to get/set data. OLE DB is another database connectivity standard. Same concept as ODBC, except the native API is COM-based instead of procedural. Because of this, if you're working in C++, OLE DB is generally preferred over ODBC. Due to implementation details, OLE DB is very easy to use from C++, but damn near impossible to use from some other languages, namely VB. So, ADO (ActiveX Data Objects) was created to make the OLE DB model accessible to all programming environments. Like RDO for ODBC, it sits between the application and the low-level data access API and mediates operations, ensuring that the stream of data retrieved from the DBMS is exposed to callers in an appropriate and convenient format. The most recent creation is ADO.Net, a set of classes that expose data access services to .Net applications. Not really based on ActiveX Data Objects, though; MS just used the ADO acronym because people associate ADO with "data access" I guess. From native C++ (as opposed to Managed C++ or C++/CLI, where you would just use ADO.Net), if the database you're connecting to only has an ODBC provider, you probably want to go with DAO+ODBCDirect (easier) or RDO (less overhead). If the database you're connecting to has an OLE DB provider, while most people just use ADO at this point, pure OLE DB is technically the best way to go. This is because when used, ADO is the real OLE DB consumer, not your application. In terms of raw performance, this inevitably adds some overhead due to both data packaging and some housekeeping code. When using OLE DB directly, that overhead doesn't exist. Hope this helps. And by the way, MySQL does indeed have an OLE DB provider. Regards, Satyric0n |
![]() |
Thread Tools | |
Display Modes | |
|
|