DLL Heaven
A Possible Solution.
After reading the gripes about using ActiveX libraries with Access, and not having any major problems myself, I was encouraged to share my technique for avoiding reference errors. The downloadable mdb uses Fully 'disambiguated' code to retrieve and replace libraries after a reference fault. The libraries are packed into a Jet Long Binary Data Field. If, when starting, the application detects a reference error for custom libraries, it gets the library from the table and writes it to disk. It then reregisters the library. This technique is also useful for distribution of simple Access applications requiring no setup application. The only caveat being any dependencies the libraries themselves require. I am not recommending this approach for all COM objects required by your application, only the custom ocx / DLLs. You could include DAO libraries by simple modification to the code bit I would advise agains it, although with the 'fix' of the reference fullpath method in A2K and XP you could look for first time startup options and pack away the current working version of DAO or ADO and restore them to the original folder on failure.
What happens if it unpacks a library and some other application fails? If a client has been using your application and it suddenly trips the library replacement code, then client has probably installed an application that 'breaks' binary compatibility. You don't guarantee your application against future third party installs that may stomp on libraries using a crap setup system. Yours will repair itself and theirs will fail. Let the other guy have the headache.

Procedures
Insert the module supplied with the MDB into an application that uses custom ocx files. When distributing your application, place the ocx / DLLs in the application directory. If the references are broken or files damaged this module will automatically fix the application for the client. Read DLL Hell for greater detail.

Function StoreReferenceFiles()
This is the function to call when the application has all references resolved and you are ready to pack the libraries away into the table.

Public Function EnumRefs()
'This is the main procedure to be called during start up. 'If it is called by form class code then that code must use fully qualified library methods and properties. And must not use libraries other then Access, VBA or DAO

Function ViewRefs()
This function does nothing more than 'pop up' a message with a list of references and their status.
Note:
All API module loading and registration now available in beta 2
Download A'97 Version and Help
Download Test MDE Access '97
Download Test MDE Access 2000

For further Information contact papwalker@ozemail.com.au
Copyright Peter Walker 2002
http://www.papwalker.com

There is still more work to be done on this project.
* Checking the COM interface of references and intelligent comparison and version checking.
* LZ compression of the library data in the table.
* Porting to use OLE storage / SQL7 in A2K adps etc.
* COM addin / wizard for Access and VBA.

Will DOT NET overcome this problem?
We'll see.

Bug List - Update
Field Naming bug found and fixed.... 02/28/02
Fix
rst("strFileName") = strFileName >>> rst("FileName") = strFileName
rst("strRefName") = strRefName >>> rst("RefName") = strRefName
Update
No longer requires external files to load and register Self OLERegisterLibraries