Re: Regarding fastest database interaction with Oracle in VC++
- From: "Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom>
- Date: Wed, 15 Mar 2006 20:16:36 -0000
Thanks Stephen,
Thanks for your kind information. But I would like to
know how can I know which OLE DB driver I am using?
If you are using ADO, then you will have a Connection object.
And the name of the "provider" (The word "provider" is Microsoft parlance
for an OLEDB driver) is a
property of Connection object. Normally speaking, you name it in the
connection string.
You can code in pure OLE DB which is fastest but you will have to write
quite a few lines to do anything.
ADO, is a lightweight COM API that sits on top of OLEDB. It provides 3 basic
objects : Connection, Command and RecordSet (there are subsidiary objects
like Fields, Field, Record, Parameters).
ADO is very easy to use and I don't believe any overhead is that much
compared to database IO.
Unlike ODBC, OLEDB does not require an interface manager. So there is no
16-bit or 32-bit ODBC utility for managing your database sources in Control
Panel. It is more direct than that.
If you install MDAC 2.8, it will install some providers for you. In
particular, it will install SQLOLEDB which is the native provider for
Microsoft SQL Server. It will install the MS Oracle provider.
You should be aware that Microsoft now regards the Jet provider (for Access
principally and also dBase, Excel, text-files) and ODBC provider as
"legacy". It stopped distributing them with MDAC 2.6.
Therefore if you need to talk to an Access database, you need to download
the Jet provider separately, it is no longer bundled with MDAC. Same with
ODBC provider. It is regarded as legacy.
Suppose you wished to work with ADO but you had no OLEDB provider for your
unusual database, but you did have an ODBC driver. Could you still program
using ADO? Yes!! This is what the ODBC OLEDB provider is for (bit of a
mouthful to say). Effectively this provider is translating ODBC to OLEDB
and back. It is a piggy-back provider. Effectively
Application <--> ADO <--> ODBC OLEDB provider <--> ODBC driver <--> database
Lastly, various Windows come with MDAC preinstalled (MDAC contains ADO,
ADOX, OLEDB & some providers, some documentation).
Windows 2000 comes with MDAC 2.5
Windows XP comes with MDAC 2.7
Windows 2003 comes with MDAC 2.8
I forget what various flavours of Service Pack upgrade these to.
You _CANNOT_, in general, uninstall MDAC.
Windows regards it as an essential system component.
You can upgrade, in general, but not go back to a lower number.
For Windows 2003 64-bit, under _NO_ circumstances attempt to update its
MDAC.
The MDAC download page specifically excludes Windows 2003 64-bit as a target
OS that the MDACs are suitable for. In any case, you should not need to. It
is the latest MDAC that comes with this OS.
MDAC is usually installed (worth going to look and poking around) in
C:\Program Files\Common Files\System
The verison of ADO can be found by looking at version information of file
C:\Program Files\Common Files\System\ado\msado15.dll
Any providers will be installed in directory
C:\Program Files\Common Files\System\Ole DB
Common providers are
MSDASQL : provider for ODBC
msdaora.dll : provider for Oracle (author : Microsoft)
OraOLEDB.dll : provider for Oracle (author : Oracle)
sqloledb.dll : provider for Microsoft SQL Server
Whether it is a
native driver or it is using ODBC, how should I know that?
Well ADO, apart from the piggy-back technique mentioned above, cannot use
ODBC drivers.
But even there, it is talking to an OLEDB provider. It has to use OLEDB
providers.
For sample OLEDB connection strings, see here
http://www.carlprothman.net/Technology/ConnectionStrings/OLEDBProviders/tabid/87/Default.aspx
What is this RecordBinding techinque?
It is specifically for Visual C++. It allows you to setup a C or C++ struct
such that when you do
pRecordSet->MoveNext(), your struct is automagically populated with the
current record.
And of course it is easy to work with C struct of data - no special objects.
You can also do AddNew()'s for new records and Update records. If fields can
have NULL values or should be NULL, that can also be handled. It is faster
as it bypasses Recordset Variants and BSTRs which are used for various field
types. At work we consistently used the wrapper classes _variant_t and
_bstr_t which are the same thing.
RecordBinding is documented here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/mdmscusingadovcextensions.asp
Example here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/mdmscexampleadowithextensions.asp?frame=true
But in my opinion, you should try and work with ADO Recordsets first, get
something working before adding in RecordBinding. It is really an
optimisation technique.
Stephen Howe
.
- References:
- Prev by Date: DAO and MS-Access
- Next by Date: Linking errors in declaring CDatabase and CRecordset objects as global
- Previous by thread: Regarding fastest database interaction with Oracle in VC++
- Next by thread: Whats the big deal about MSADO<>.DLL?
- Index(es):
Relevant Pages
|
