Revisiting mdb/adp files as libraries

[Glenn Davy]

Hi all

I'm wanting to build some 'libraries' of functions and classes that I can
share around between various front ends which all share a common backend.
I realise from the archives, that this has been discussed a little in the
past, however I just want to confirm my understanding on a few points.

Q1) Class visibility - While its technically possible to see classes in a
referenced mdb file by exporting, tweaking and re-importing (see
http://www.mvps.org/access/modules/mdl0034.htm) - this clearly isn't
standard behaviour. This may remove some obstacles to building the app the
way I'd like, but I am concerned that if a future version of access
doesn't respect this tweak (VB_Exposed=true) then I may be faced with
'retro designing' the application. Thoughts?

Q2) Inter reference scope - given:

A.mdb -references->B.mdb - which referencernces-> c.mdb
AND
A.mdb -references->D.mdb

Is it possible (which it doesn't seems to be to me) for:
B.mdb to utilise code in A.mdb, or even D.mdb?

If its possible could you share how ?
Thanks all in advance
Glenn

[Tony Toews]

Glenn Davy <gS***********@tpg.com.au> wrote:

Q2) Inter reference scope - given:

A.mdb -references->B.mdb - which referencernces-> c.mdb
AND
A.mdb -references->D.mdb

Is it possible (which it doesn't seems to be to me) for:
B.mdb to utilise code in A.mdb, or even D.mdb?

<shudder> No, AFAIK it's only downwards. In your scenario B can't utilize code in A
or D.

But I'm not at all sure I'd want to setup such a complex scenario. I can see having
a "library" of utility code. Which I have. I can see having multiple functional
MDEs called from a "menu" mdb. Any of those would reference the library MDE.
A > B > U, A > C > U, A > D > U, etc.

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

[Glenn Davy]

On Thu, 24 Jun 2004 04:19:40 +0000, Tony Toews wrote:

Glenn Davy <gS***********@tpg.com.au> wrote:

Q2) Inter reference scope - given:

A.mdb -references->B.mdb - which referencernces-> c.mdb
AND
A.mdb -references->D.mdb

Is it possible (which it doesn't seems to be to me) for:
B.mdb to utilise code in A.mdb, or even D.mdb?
<shudder> No, AFAIK it's only downwards. In your scenario B can't utilize code in A
or D.

But I'm not at all sure I'd want to setup such a complex scenario. I can see having
a "library" of utility code. Which I have. I can see having multiple functional
MDEs called from a "menu" mdb. Any of those would reference the library MDE.
A > B > U, A > C > U, A > D > U, etc.

Yes I think you're correct re complexity - I was putting my most primitve
functionality at the top of the tree - it might be a limitation not to be
able to traverse this tree, but I think in this instance at least, its
simply saved me from some muddy thinking. I'll see how it looks after I
refactor it a little.
Glenn Tony

[david epsom dot com dot au]

q1: My understanding is that the class tweak is more
difficult to implement in A2K3 than it was in A97. You
may want to search around for more information on that.

q2: Yes, an access project can use code in any loaded
class/module. However, you don't have the class
libraries of any child or indirectly referenced projects
at compile time, so you have to use run,eval,SQL, runcode
or whatever to prevent early linking of that code if you
are going to use an MDE. (If you are using an MDB, then
you can live dangerously: the code will only crash if
references can't be resolved as code is loaded and demand
compiled).

For example, I've got code in my second level library
(c.mdb) which calls back into my base projects (a.mdb)
to get application customisation data set at build time.

We also have table driven code in the second level
library that calls back to the mid level modules (it
is used to configure and run reports in the mid level
modules). It is table driven, so it was always going
to be eval/run anyway.

And we used to have code in the mid level modules that
called sideways (from d.mdb to b.mdb). It simplified our
build process and made it more robust by allowing us to
avoid a reference dependency chain. That code still exists,
but we were eventually able to simplify the reference
chain to three levels by consolidating libraries.

(david)

"Glenn Davy" <gS***********@tpg.com.au> wrote in message
news:pa****************************@tpg.com.au...

Hi all

I'm wanting to build some 'libraries' of functions and classes that I can
share around between various front ends which all share a common backend.
I realise from the archives, that this has been discussed a little in the
past, however I just want to confirm my understanding on a few points.

Q1) Class visibility - While its technically possible to see classes in a
referenced mdb file by exporting, tweaking and re-importing (see
http://www.mvps.org/access/modules/mdl0034.htm) - this clearly isn't
standard behaviour. This may remove some obstacles to building the app the
way I'd like, but I am concerned that if a future version of access
doesn't respect this tweak (VB_Exposed=true) then I may be faced with
'retro designing' the application. Thoughts?

Q2) Inter reference scope - given:

A.mdb -references->B.mdb - which referencernces-> c.mdb
AND
A.mdb -references->D.mdb

Is it possible (which it doesn't seems to be to me) for:
B.mdb to utilise code in A.mdb, or even D.mdb?

If its possible could you share how ?
Thanks all in advance
Glenn

[Glenn Davy]

On Thu, 24 Jun 2004 18:07:22 +1000, david epsom dot com dot au wrote:

q1: My understanding is that the class tweak is more
difficult to implement in A2K3 than it was in A97. You
may want to search around for more information on that.
Thanks for the tip, you're understanding is correct - I've just compared
2000, 2002 and 2003. In access 2000 and 2002 it was quite simple to
impliment, but in 2003 things don't work properly.

q2: Yes, an access project can use code in any loaded class/module.
Just to clarify - when you say any class module, you mean class module
which has been tweaked?
However, you don't have the class libraries of any child or indirectly
referenced projects at compile time, so you have to use run,eval,SQL,
runcode or whatever to prevent early linking of that code if you are
going to use an MDE. (If you are using an MDB, then you can live
dangerously: the code will only crash if references can't be resolved as
code is loaded and demand compiled).
Again to clarify by rephrasing in my own words - to get around compliation
issues, by using say, eval you can execute (and so see ) upstream
code, which access wouldn't see during compile?

For example, I've got code in my second level library (c.mdb) which
calls back into my base projects (a.mdb) to get application
customisation data set at build time.

Good example of when this could be needed - but what do you mean by build
time?

Thanks for your thoughts david
Glenn

[david epsom dot com dot au]

> Just to clarify - when you say any class module,
class or module - I really meant an MDE, which appears
in the object viewer as a class with function methods.

issues, by using say, eval you can execute upstream Yes
but what do you mean by build time?
We have 10-15 mde's in the project. The build process
includes setting the build date, version number,
application name, menu's, etc.

(david)

"Glenn Davy" <gS***********@tpg.com.au> wrote in message
news:pa****************************@tpg.com.au... On Thu, 24 Jun 2004 18:07:22 +1000, david epsom dot com dot au wrote:

q1: My understanding is that the class tweak is more
difficult to implement in A2K3 than it was in A97. You
may want to search around for more information on that.

Thanks for the tip, you're understanding is correct - I've just compared
2000, 2002 and 2003. In access 2000 and 2002 it was quite simple to
impliment, but in 2003 things don't work properly.

q2: Yes, an access project can use code in any loaded class/module.

Just to clarify - when you say any class module, you mean class module
which has been tweaked?

However, you don't have the class libraries of any child or indirectly
referenced projects at compile time, so you have to use run,eval,SQL,
runcode or whatever to prevent early linking of that code if you are
going to use an MDE. (If you are using an MDB, then you can live
dangerously: the code will only crash if references can't be resolved as
code is loaded and demand compiled).

Again to clarify by rephrasing in my own words - to get around compliation
issues, by using say, eval you can execute (and so see ) upstream
code, which access wouldn't see during compile?

For example, I've got code in my second level library (c.mdb) which
calls back into my base projects (a.mdb) to get application
customisation data set at build time.

Good example of when this could be needed - but what do you mean by build
time?

Thanks for your thoughts david
Glenn