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
OleDBPro vs ADOs - OleDBPro is
faster, simpler, easier, lighter, more extensible than ADO, ADOX and ADOMD!
- ADOs are mainly designed for internet development and supporting
automation. It must be used by all kinds of languages such as Visual Basic,
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.
- 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.
- 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.
- 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
- 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.
- 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.
- OleDBPro (128k) is much smaller in size than ADO (477k), ADOX (181k) and
- 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
- 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
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>.
OleDBPro is much simpler than ATL consumer
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
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
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
OleDBPro vs Borland ADOExpress - OleDBPro
is faster and more extensible with more functionalities than ADOExpress.
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.
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
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!
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.
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.