Firstly, I'm not sure if Library database is the correct term. I'm talking
about Dbs to which you set a reference in the VBA references section.
Secondly apologies for sort-of reposting this question, but I drew blanks
last time. Now assuming I have several referenced (library?) databases in my
main database, how do I get the names of all the forms in all the Dbs?
CodeProject.AllForms.Count gives me the correct number of forms if I am in
that referenced database. What I think I need is a method of looping through
all the different CodeProject names in the main database, but there isn't a
sort of CodeProjects parent object. Or somehow moving the focus to each
reference in the library and seeing how many forms there are. Any help
gratefully received Phil

Phil wrote:


Library is the right term. And, No, there isn't any parent
object for all the code projects.

Because each database only knows about its own objects (or
documents), you have to use a procedure in each database to
refer to the objects in that database. E.g. to open a form
in a library database, the library needs its own routine to
open its forms. Then same is true to refer to the AllForms
collection in a library,

So just add a public function to each library to get its
CodeProject.AllForms.Count.

You can loop through the References collection and somehow
(via some naming convention?) pick out the libraries of
interest

--
Marsh

"Phil" <phil (AT) stantonfamily (DOT) co.uk> wrote in
news:ihh2ej$i7u$1 (AT) speranza (DOT) aioe.org:

Marshall is right that you either have to open a database variable
(or in the case of the AllForms collection, you'll need to open an
ADO connection object), or have a function in your library that
returns either its AllForms object, or its connection. I'm not
entirely sure how code like that would run when in a library, since
it might return the corresponding objects for the CurrentDB -- just
checked, and yes, that's the way it works:

Public Function LibraryAllForms() As Object
Static objAllForms As Object

If objAllForms Is Nothing Then
Set objAllForms = CurrentProject.AllForms
End If
Set LibraryAllForms = objAllForms
End Function

....when this function is in a library database that is referenced,
it will return the count of AllForms in the database open in the UI
when it is run, not in the referenced database.

So, I suspect you're going to have to walk the references collection
and get the library name and open it as a database variable (or an
ADO connection object).

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

"Phil" <phil (AT) stantonfamily (DOT) co.uk> wrote in
news:ihh2ej$i7u$1 (AT) speranza (DOT) aioe.org:

BTW, I intended to say that I think it's inadvisable to create a
reference, as it makes deployment much harder.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

On 24/01/2011 01:36:54, "David-W-Fenton" wrote:
Thanks David & Marsh

Have some work to do to implement your suggestions. Will come back when I run
into problems.

Basically I am trying to create a menu database (AccDe) which I can
incorporate into any other database by simply setting a reference to it and
providing the neccessary tables. By doing this I hoped that any design
changes in the Menu.AccDe would automatically be incorporated into all other
Dbs without actually having to do anything. I appreciate that I would have to
send each client the new Menu.Accde, but that would be the limit of wha I
needed to do. If I can get that working smoothly, then I want to extend it to
say a Mailmerge database Phil

Hi Phil,

Probably your way of working is a little different from mine, though
we both use reference databases.

This is what I do:
Each user application is a user database with a reference to a General
database. All functionality that is common to all user applications,
is stored in the “always learning” General database, which on this
moment encloses more then 90% of the total functionality.
An update is always the new user database and the General database on
that moment. This combination makes that I do not need to care of all
kind of versions.
Changes in the General database are immediately reflected in all user
applications. When these changes have their effect on the
(standarized) forms in the user databases, than the forms can be
updated with one click of a button.
In this concept it is not necessary that the General database knows
anything of user tables. All procedures (and forms) in the General
database are triggered from the user database.

Imb.

"Phil" <phil (AT) stantonfamily (DOT) co.uk> wrote in
news:ihmvg0$skt$1 (AT) speranza (DOT) aioe.org:

But there are pretty significant problems than that:

1. the MDE vs. MDB problem (at multiple levels)

2. the deployment issue -- put it in the same folder and let the app
assume it's there, or put it on the network (like a shared data
file) and let all front ends refer to it? Either way, the reference
has to be fixed up to match the location.

Without a reference, you can do some of the same things using .Run.
While you still have to know where the file is, the MDE/MDB issue is
moot and if it's in the wrong place, it won't break the rest of the
application (as is the case with a broken reference).

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

imb <imb4u (AT) onsmail (DOT) nl> wrote in
news:3a1deadc-c844-41e5-a87f-b2d436f410b1 (AT) u6g2000yqk (DOT) googlegroups.com
:

This means no MDEs, right? That would be a complete showstopper for
a large population of Access developers, I think. It wouldn't be for
me in all my apps, but for some, it would be.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

On 26/01/2011 18:56:35, imb wrote:
Imb

Thanks again for you input. We are both working on very similar lines.
One obvious difference is that my general db (Menu.AccDe) currently is
comparatively small compared to the user Db (that may change) and there ar no
tables in the Menu Db. All the tables for the forms in the Menu Db come from
the User Db. I seem to be struggling a bit to ensure that the reference to
the Menu db is the latest version. I have a feeling that if the User Db has a
reference to the Menu db that it does not reload it. I can remove the
reference (Access.References.Remove RefName), but then I have to compact and
repair the Db before adding a reference to the latest version of the menu Db.
If I don't do that, I end up with apparently 2 references in the project
explorer, but only 1 reference in the Tools->References section.
As far as I know it is not possible to use VBA to compact and repair.
I can't find any way of removing the reference from the Project explorer
after running Access.References.Remove RefName. Any help gratefully received
as ever

Thanks

Phil

Hi David,

This means no MDEs, right?
I have been thinking of what the basis could be for this question.

1. The refreshment of the forms by one click on a button?
This is not done by the user, but is done during development when the
current forms do not match anymore with the “evolved” General
database.
Also, just before sending a new version the forms are refreshed, the
user database and General compacted, en send via email as zipped
files.
The user unpacks the two zip-files, and places them in the right
directory, and all works fine again.

2. The combination of an user.mde and General.mde?
Technically this is possible, but a little unhandy (but you know all
about that) because you have to change the reference. But this also
can be automated. In fact I do this already when the user uses an
different directory for placing the application in then I have in my
development environment. I never did this for MDE’s, however.

But yes, I don’t use MDE’s, for other reasons.

Imb.