Why do you need to use OleDBPro instead of ADO, Borland ADOExpress and ATL consumer templates?

        You may know Microsoft provides us ADOs and ATL consumer templates for free. Why do you need to use this OleDBPro module? The answer to this kind of question is simple. OleDBPro module has its own features and many advantages in the C++ development environment. Some of advantages are very crucial for your development. For the sake of clearness, let us quickly compare OleDBPro with ADOs first, and then with ATL consumer templates.

OleDBPro vs ADOs - OleDBPro is faster, simpler, easier, lighter, more extensible than ADO, ADOX and ADOMD!

1. ADOs are mainly designed for internet development and supporting automation. It must be used by all kinds of languages such as Visual Basic, Java, JavaScript, VBScript, and so on. It is not optimized for C++ development. Most of the examples and tutorial books are written for the application of ADOs for internet and Visual Basic developments. However, OleDBPro is optimized purely for C++ development.
2. ADOs need to extensively convert all native data into VARIANT data inside and supports data collections. All of these drawbacks are totally eliminated in the OleDBPro module even though it supports VARIANT data. It makes the OleDBPro module runs faster.
3. For parameterized statements or stored procedures, ADOs only send one set of parameter data into a data source. OleDBPro supports sending multiple sets (20, 40, ....) of data into a data source to reduce the data movement over expensive network by default. OleDBPro uses this way to boost data accessing performance with great ease and simplicity. See the template CBatchParam<T> and example MultiProcs.
4. OleDBPro has a UNIQUE feature, Just-In-Need fetching, at this writing time. For many cases, it can improve record navigation especially for a query with a big number of records, as shown in the example FastAccess.
5. Some OLEDB providers have specific interfaces. ADOs can't fully take advantage of these provider-specific interfaces. However, OleDBPro can take advantage of them. For example, SQL Server exposes an interface IRowsetFastLoad. We can use it by extending CRBase in this module for inserting data into a table at the fastest speed as shown in the example FastLoad. OleDBPro has better extensibility than ADO.
6. In C++ development, it is still difficult and tedious to use ADOs because we have to convert all of VARIANT data back again into native C++ data type and do this kind of dirty work. It further slows down data accessing. If using OleDBPro module, this kind of work is completely avoided. It is much simpler to use OleDBPro module than ADO.
7. OleDBPro (128k) is much smaller in size than ADO (477k), ADOX (181k) and ADOMD (169k).
8. You can get all the source codes of OleDBPro, but you can't get source codes of ADO, ADOX and ADOMD.

OleDBPro vs ATL consumer templates - OleDBPro, a complete solution, is much simpler and easier to use than ATL consumer templates, and better in many other aspects.

1. OleDBPro provides a complete solution but ATL consumer templates don't.
           As declared in Benefits of OleDBPro and Wrapped OLEDB Interfaces in OleDBPro, OleDBPro can deal with any valid statement as long as a provider is able to do so. However, ATL consumer templates only supports OLEDB specification version 1.1. ATL consumer templates don't wrap TView, TBinder, TRow, TStream and TDataset objects as well as chaptered rowset.

2. OleDBPro is faster than ATL consumer templates.
           Without use of OleDBPro specific functionality, CRBase in OleDBPro is always faster than CBulkRowset with a dynamic accessor in ATL consumer templates. CRBase can be configured to be as fast as CBukRowset with a user well-defined accessor at run time. If using OleDBPro unique features, for example, Just-In-Need fetching, OleDBPro is definitely faster than ATL consumer templates. By default, OleDBPro uses the batch mode to retrieve data from and send data into a data source silently for fast data movement over network, but ATL consumer templates don't. See the class CRBase and the template CBatchParam<T>.

3. OleDBPro is much simpler than ATL consumer templates.
           It can be complicate and difficult to use ATL consumer templates, depending on involved statements and rowsets because you have to deal with DBBINDING structures and one of accessors, CAccessor<T>, CDynamicAccessor, CDynamicParameterAccessor and CManualAccessor derived from CAccessorBase. However, if you use OleDBPro module, you will not cope with these DBBINDING and accessors directly. OleDBPro module automatically manages them for you inside. This OleDBPro feature reduces lots of pitfalls and tricks of OLEDB programming. Additionally, OleDBPro provides better ways to manage binary large objects (BLOBs) and data types conversion which are important in software developments.

4. OleDBPro is better in many other aspects than ATL consumer templates.
           OleDBPro has various ways including both all the common ones and the OleDBPro-specific ones to improve data accessing performance.
           Because all the OleDBPro classes and templates are 100% dynamic, you can easily extend them, but will never define a static user record at development time. If you use ATL consumer templates, you will have to do so for many of your statements and procedures. This OleDBPro feature leads to more concise codes and lighter software components. Additionally, OleDBPro can also use its templates to further light components.
           OleDBPro can easily take advantage of use of all of MS various data services but you can't easily use some of MS data services with ATL consumer templates.
           Some interfaces such as IViewFilter, IRowsetIndex, IRowsetFind, and so on are difficult to use. These interfaces are not wrapped in ATL consumer templates. However, OleDBPro module encapsulates them and they are simple to use.

OleDBPro vs Borland ADOExpress - OleDBPro is faster and more extensible with more functionalities than ADOExpress.

1. OleDBPro is much faster than ADOExpress. ADOExpress is a wrapper of ADO. As said in the above, OleDBPro is faster than ADO. Certainly, OleDBPro runs much faster than ADOExpress.

2. OleDBPro almost wraps all of functionality of OLEDB version 2.6, but ADOExpress just wraps a part of ADO functionality. As said in the above, OleDBPro provides more functionality than ADO. Certainly, OleDBPro has more functionalities, including all of ADOExpress features, than ADOExpress. There are many features of OleDBPro which can't be found in ADOExpress. 

3. OleDBPro is highly extensible but ADOExpress is not. You can extend OleDBPro, and add up to all of features of OLEDB. However, you can't do this with ADOExpress!

4. OleDBPro makes your application run at the low foot print. If you use ADOExpress, you also bring big guy, ADO. If you use OleDBPro, no ADO is involved.

5. You are able to get both OleDBPro library and its source code of OleDBPro at the price of ADOExpress, but you can't get source code of ADOExpress. Source code of OleDBPro definitely helps you learn OLEDB technology. OleDBPro is a component, also a tool to help you study OLEDB.