PUtting an Access database in the References list

[Margaret Bartley]

I've manually added an Access database to my References collection.
I've got a file called "books1.mdb". I selected it using the Browse button
on the Refernces dialog box.
I now have "books1" in my list of Refernces, and I've checked it.
The location is "C:\MyDocs\SML\Data"

So, now how do I reference it, so I can get to the collection of modules in
it?


I've tried various combinations like below:

Dim oAcc as Access.Application
Dim db As Database
Set oAcc = New Access.Application
set db=oAcc.database(books1)

but I get a "Type Mismatch" on the New Access.Application.Database, other
error.

I've tried
Dim oDB as books.application
but that doesn't work, either.

Basically, I don't know if I need to first create an Access application
object, and then use the books1 as a database, or if books1 is my
application object.

 

[Stuart McCall]

I've manually added an Access database to my References collection.
I've got a file called "books1.mdb". I selected it using the Browse
button on the Refernces dialog box.
I now have "books1" in my list of Refernces, and I've checked it.
The location is "C:\MyDocs\SML\Data"

So, now how do I reference it, so I can get to the collection of modules
in it?


I've tried various combinations like below:

Dim oAcc as Access.Application
Dim db As Database
Set oAcc = New Access.Application
set db=oAcc.database(books1)

but I get a "Type Mismatch" on the New Access.Application.Database, other
error.

I've tried
Dim oDB as books.application
but that doesn't work, either.

Basically, I don't know if I need to first create an Access application
object, and then use the books1 as a database, or if books1 is my
application object.

Once you've referenced a library database, you can call it's code just as if
it existed in your application. No need for automation at all. So if you
have a function in the library called MyFunction, just simply call it by
name, as usual:

MyResultVar = MyFunction()

Hope that helps

 

[Tony Toews [MVP]]

Once you've referenced a library database, you can call it's code just as if
it existed in your application. No need for automation at all. So if you
have a function in the library called MyFunction, just simply call it by
name, as usual:

And hopefully there are no duplicate function names in the references
MDB. <smile>

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Stuart McCall]

And hopefully there are no duplicate function names in the references
MDB. <smile>

Well yes <g>. On the other hand the fact that the local procedure takes
precedence and effectively 'overwrites' the lib version can be quite handy,
especially when developing add-ins (which comprised about 60% of my working
life). As I'm sure you know, if you make 'on the fly' mods to a loaded
add-in, you're actually changing the in-memory instance and not the one
stored in the add-in. So when you close the CurrentDb you're using to test
the add-in, all your changes are quietly lost.

If you copy the routine from the CodeDb to the CurrentDb and make your
changes there, your tests will utilise this local copy. You can close and
re-open the CurrentDb as much as you like, without losing your changes. When
you're satisfied that the changes are good, the routine can be copied back
into the CodeDb and the local copy destroyed.

 

[Michel Walsh]

If there is name collision, you can remove ambiguity by preceding the name
of the function with the name of the reference:

MyBook1.MyFunction( ... )


Vanderghast, Access MVP

 

[Margaret Bartley]

Once you've referenced a library database, you can call it's code just as
if it existed in your application. No need for automation at all. So if
you have a function in the library called MyFunction, just simply call it
by name, as usual:

MyResultVar = MyFunction()

Hope that helps

Thank you for replying, it's not really what I'm trying to do.
I'm trying to get at the Modules collection of the attached database.
I'm trying to find a procedure I know is in one of my databases.

I already have the structure to loop through all my databases and get a list
of DAO objects and their properties, but I can't get at the modules. I was
told that I would have to attach the database as a Reference to be able to
do that. Maybe that advise was wrong.

 

[Stuart McCall]

Thank you for replying, it's not really what I'm trying to do.
I'm trying to get at the Modules collection of the attached database.
I'm trying to find a procedure I know is in one of my databases.

I already have the structure to loop through all my databases and get a
list of DAO objects and their properties, but I can't get at the modules.
I was told that I would have to attach the database as a Reference to be
able to do that. Maybe that advise was wrong.

Ok I'm with you now. No you don't need to set a reference to the remote mdb,
and you will need to use automation, something like this:

Public Function testRemoteModules(MdbFilePath As String)
Dim mdl As Access.AccessObject

With New Access.Application
.OpenCurrentDatabase MdbFilePath
For Each mdl In .CurrentProject.AllModules
Debug.Print mdl.Name
Next
.CloseCurrentDatabase
End With
End Function

Paste that into a standard module, then test from the immediate window,:

testRemoteModules "C:\Temp\MyFile.mdb"

That should get you started.