Missing Microsoft Activex Data Objects 61 Library
Eleanore Bansmer
Objects instantiated with CreateObject are late-bound, which means that they are not strongly typed and command-line completion is disabled. However, it does allow you to skip referencing the ADO library from your project, and enables you to instantiate specific versions of objects. For example:
The simple answer to the question is yes. Pick the version of ADO you
want to use and ignore MDAC.A more detailed and really boring answer follows. [You can easily and
safely exit here.]When ADO was introduced and for most of its history it was supported
by a team separate from the development or system groups. It had
separate release cycles from any other product. Products that shipped
with MDAC, included whatever current version was available and could
be later updated with subsequent MDAC releases.The MDAC was the keystone of what Microsoft called "Universal Access",
the idea of a single assortment of tools providing access to any data
source through a single access library. ODBC had gone a long way to
providing this sort of functionality, but ODBC was tied to a single
hierarchical data model - ADO and OLE DB removed this limitation.To implement this grand strategy MS adopted its other rising star -
COM - that's where and why OLE is so much a major player.A major point of confusion is that while MDAC releases were/are named
after the most current version of ADO (the ActiveX Data Objects) they
supported - the MDAC is actually a package of diverse though related
components - the principle catagories being OLE 'system' support, OLE
DB components and OLE DB Providers, and the ADO data access library.
(These packages originally also included ISAM and ODBC drivers, and
the DAO data access library, ie - one-stop shopping for all data
access.)The strategy was grand and ambitious. Perhaps too ambitious as
problems appeared almost immediately in trying to keep such a diverse
asssortment of tools all current (and provide bug fixes and upgrades)
in a single package. Or perhaps it was mostly marketing and MS never
really expected it to be all that Universal in the first place.One problem was the ADO data access libraries, the second was the
improvement and fixes of the OLE/OLE DB components. While ADO itself
is essentially non-system dependent, OLE is totally system dependent,
and OLE DB was product dependent as well as having a foot in both ADO
and OLE.It would take too long to document all the various changes to the
MDAC package in its migration from a 'universal' store house to a
'specific' ADO/OLE tool, and such information is
readily available on the web, but to highlight a few ...The ADO libraries improved in features and needed bug fixes the
fastest . (Probably why MDAC releases were named after ADO versions.)
To manage this MS adopted the strategy to provide a single named
component that supplied multiple interfaces. This simplified four
things:
1) With each new ADO release MS simply provided a new interface to the
existing component,
2) Each version had many features in common with previous versions.
Keeping them in the same component meant they only had to have one set
of code for all,
3) as bug fixes and improvements often affected more that one version
of ADO they could provide those fixes at a single point,
4) they avoided having multiple versions laying around - one file
replaced the old.
Each new release provides support for all previous versions of ADO.Stop and think what the packages might have looked like if MS hadn't
adopted this strategy. We could have had ...
msado15.dll
msado2.dll
msado2b.dll
msado25.dll
msado25b.dll
msado25c.dll
msado25d.dll
msado26.dll
msado26b.dll
msado26c.dll
msado27.dll
msado27b.dll
msado28.dll
msado28b.dll
...
If having multiple interfaces for one component confused developers
just imagine what a mess the above would have been.The same problems existed for the OLE components and MS adopted the
same strategy. For different O/Ss (and the OLE components) MS simply
provided separate MDAC packages. That's why there is a different one
for Win2000 and below and another one for XP. (Both labeled '2.8' by
the way.)For partly political reasons (MS announced the death of DAO several
times and really wanted to push migration to SQL server) and simply
because the under-lying technology and dependences were so different,
DAO, ISAM, and ODBC was removed from the MDAC. Those components are
supplied in separate JET packages.The MDAC has confused and caused doubt for years for otherwise
competent developers (Mr. Toews's article an excellent example), and
for absolutely NO reason. A zillion bytes have been wasted when the
rule has ALWAYS been very simple and valid from Day One. Pick the
version of ADO you want to use. If a client doesn't have the
components to support that version then have them download or supply
the latest 'n greatest MDAC package - NO MATTER WHAT VERSION OF ADO
YOU ARE USING.In general, previous to Vista, every client and developer has always
been advised to download the most current MDAC package appropriate for
their system. Not necessarily to support a higher version of ADO but
to take advantage of improvements and fixes for both ADO and OLE.
Again - NO MATTER WHAT VERSION OF ADO A PARTICULAR PRODUCT IS USING.A developer can also take it as a general rule to develop against ADO
2.5. This is because
1) after all this time it is the most stable,
2) the most clients already have it no matter what platform they are
using, and
3) 2.5 provides the bulk of the features a developer
commonly uses.
But this really has little to do with MDAC, except obviously the
client has to have an MDAC installed that has the components to
supports the version of ADO a program uses. But if everyone simply
installs the latest 'n greatest - then it was not, is not, nor should
it ever be, a problem. [there were a few issues with 2.6, thus the
subsquent quick release of 2.7 and 2.7rtm, followed by their equally
quick demise with the release of 2.8.]IMHO If a developer knows his targets are XP and above then should use
ADO 2.8, but the advantage is only additonal features (which as
already noted you likely won't need but nice to have if you do. )
and by now it is equally stable. And last - all of this is becoming a non-issue since MS now includes
ADO and OLE/OLE DB as part of Vista and Win7 supplied components (and
updated by SPs and not from a separate 'universal' package). MDAC is
gone. So pick any version of ADO you want* it will be supported.MS also now supply OLE DB providers as separate downloads. OLE DB and
OLE is likely to remain a platform supported feature.Whew!
-ralph[* I don't advise picking anything previous to 2.5 as there are
differences in behavior and not all the bugs have been fixed.]
Traditional approaches to leveraging Excel in data entry have end users key data into a formatted spreadsheet, save it to a shared directory, then run a server side program to check data, and if everything is okay, update the database. This approach has multiple objects on different platforms involved in a single task complicating development and maintenance. In addition, validation results are delivered well after entries have been made frustrating end users.
I tried this and am getting a (run time error) the below error on line
Range("dataSet").Select
not sure what i am missing. any help will be much apreciated
can one of you help me resolve this?
Occasionally the problem might be that Access is unable to locate the reference, which will be indicated by the word "Missing" shown next to the reference location. If this is the case then uncheck the reference and close the references dialog. Next, open the references dialog again, locate the library from the list and re-check the reference that was missing.
Finally, whether programming in Access 97, 2000 or later it is also recommended that you also explicitly close and destroy your DAO objects after use to free up system resources and prevent database bloat. This is accomplished using the "close" method and setting the object variable to "Nothing", shown at the end of the example function above.
If the library is not even shown, you may need to re-register it. Click the Windows Start button, and choose Run. Enter regsvr32 followed by the full path of the library file. Include quotes if the file name contains spaces, e.g.:
regsvr32 "c:\program files\common files\microsoft shared\dao\dao360.dll"
Occasionally, the problem is not solved until you unregister the library and re-register it. Uncheck the missing library in Access. Close Access. Issue this command, and then the one above to re-register it:
regsvr32 -u "c:\program files\common files\microsoft shared\dao\dao360.dll"
Re-register it (as above). Open Access, and select the library reference again.
Inconsistencies and data corruption can result from referencing the wrong library for your version of Access. For example, the DAO 3.5 library was designed for Access 97, whereas DAO 3.6 is designed for Access 2000, 2002, and 2003. Access 2007 uses the ACEDAO library to give you the new functionality in the private JET engine. Use the table below to ensure you reference the correct files for your version of Access.
ADO stands for ActiveX Data Objects. It is a more generic library, designed to handle data from sources other than Access tables (SQL Server) and interfaces other than Access (e.g. web-based.) If you are working on these enterprise databases, you don't need an explanation of ADO here.
To provide this type of selective protection, the new workaround relies on the fact that, by default, Internet Explorer runs with Protected Mode turned on. This means that the iexplore.exe process runs at a low integrity level. For more information on what this means and how this works, refer to -us/library/bb250462.aspx. As mentioned in the article, the integrity mechanism makes it possible to block processes from being able to write to securable objects (such as files) that have a higher integrity level. One thing that the article does not mention, however, is that it is also possible to block a process from being able to read or execute securable objects at a higher integrity level. This is done by applying a special integrity level entry to the Access Control List (ACL) for an object. Later on in this post, we will walk you through how to do this for OLEDB32.DLL such that Internet Explorer cannot read or execute it.
dd2b598166