So far, I did not  need to use the References collection. Having read the
help file I run into the <References.AddFromFile(strFileName)> function
which links the application to another library (I think another .mde file
would suit here as a library to link to). So I moved all the common
functions to another .mdb, and later created the  respective .mde file for
the customer to use. The common.mdb was compiled OK as a stand alone.mde ,
and then I used that .mde app as a reference from the main app to compile
it.

BUT: Since the common.mde file, which appears in my local references dialog,
resides in my own directory structure, how can I provide it to the customer
who has another dir structure on his computer? Isn't the reference's path
(used at compilation time) hardcoded?

Also, isn't it the same as if someone has installed MS-Office in another
directory than the default, so the proper VBA, especialy OLB, DAO files are
not found at the same positions as with the developer's computer?

Again, what if the customer has a newer version of Access installed? (I use
Acc2000). How can a previous version work in a newer environment
(Acc2002,2003), since there are different .OLB names for Access lib
(MSACC9.OLB and so on...)

And to conclude, how can I use the References.AddFromFile(...) function in
the above scenario? It would be nice if I could determine the Access version
and then linked to the proper lib at runtime (or prompt the user to goto the
proper directory to find the file). But then, would the previous hardcoded
reference be replaced by the one at runtime or not?

All those questions...urghh. I 'll leave you all, to sleep on it

TIA