Accessing subforms in a library database...

[dommo]

Hi all, I've had a frustrating few days trying to get access to a subform
that I've added to a library database.

The scenario is this: I've been developing a suite of databases as part of a
'Czech language reference' project, and during the development process have
generated a large number of useful functions, class modules, tables, and
forms, which are often needed in more than one of the satalite databases.
Some of my forms are built from subforms (with associated class modules) that
are exactly the same for more than one of the main forms in my system.

I had been running about deleting and re-importing these objects as I made
fixes, until I found out (to my initial delight!), that Access supported a
mechanism of 'library' databases (see
http://www.microsoft.com/technet/archive/office/office97/maintain/off413ef.mspx?mfr=true).
However, despite the promises in that document, I've been unable to gain
access to forms, macros, queries, etc. in the library database. In fact,
until I came accross the workaround for class modules (see
http://www.mvps.org/access/modules/mdl0034.htm), I was ready to forget the
whole idea!

My immediate need is to connect a form in the main database with a subform
in the library database. The problem is that Access complains it can't find
the subform when I try try to open the main form (it seems not to be able to
see any of the forms, macros, etc. in the library database at all). I've
tried to find some way of proving scope for the subform (eg.
'MyLib.sbfMySubform'), but to no avail.. I've already posted a question on
the 'microsoft.public.access.modulesdaovba' discussion group, but the only
answer I've had so far is that it can't be done directly. So my question is,
can it be done via automation?

By the way, it appears that Microsoft went out of their way to hide library
objects (see http://support.microsoft.com/kb/160011/en-us for details), but
no explanation or or alternative method of use is offered!! Can anyone help
me before I run out of hair?!

Thanks guys!
Dom.

 

[Cindy M.]

Hi Don,

Since you haven't gotten a response here, try asking in an Access-specific newsgroup.

Hi all, I've had a frustrating few days trying to get access to a subform
that I've added to a library database.

The scenario is this: I've been developing a suite of databases as part of a
'Czech language reference' project, and during the development process have
generated a large number of useful functions, class modules, tables, and
forms, which are often needed in more than one of the satalite databases.
Some of my forms are built from subforms (with associated class modules) that
are exactly the same for more than one of the main forms in my system.

I had been running about deleting and re-importing these objects as I made
fixes, until I found out (to my initial delight!), that Access supported a
mechanism of 'library' databases (see
http://www.microsoft.com/technet/archive/office/office97/maintain/off413ef.mspx?mfr=true).
However, despite the promises in that document, I've been unable to gain
access to forms, macros, queries, etc. in the library database. In fact,
until I came accross the workaround for class modules (see
http://www.mvps.org/access/modules/mdl0034.htm), I was ready to forget the
whole idea!

My immediate need is to connect a form in the main database with a subform
in the library database. The problem is that Access complains it can't find
the subform when I try try to open the main form (it seems not to be able to
see any of the forms, macros, etc. in the library database at all). I've
tried to find some way of proving scope for the subform (eg.
'MyLib.sbfMySubform'), but to no avail.. I've already posted a question on
the 'microsoft.public.access.modulesdaovba' discussion group, but the only
answer I've had so far is that it can't be done directly. So my question is,
can it be done via automation?

By the way, it appears that Microsoft went out of their way to hide library
objects (see http://support.microsoft.com/kb/160011/en-us for details), but
no explanation or or alternative method of use is offered!! Can anyone help
me before I run out of hair?!

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or reply in the
newsgroup and not by e-mail

 

[dommo]

Hi Cindy,

Thanks, but I've already done that, and the general concensus is that it
can't be done.. It seems crazy to me, and as I said before. Very frustrating..

I'm rapidly coming to the conclusion that the only 'solution' is to write
some code that automatically re-imports the subforms from the library into
the main db if they're they're newer. It's a horrible workaround though, for
a problem that shouldn't exist. I mean, libraries are supposed to provide a
means to _avoid_ duplication, not add to it!!

An explanation from MS would be fantastic... Any MS officials willing to
volunteer??

Dom.

 

[Cindy M.]

Hi =?Utf-8?B?ZG9tbW8=?=,

Thanks, but I've already done that, and the general concensus is that it
can't be done.. It seems crazy to me, and as I said before. Very frustrating..

I'm rapidly coming to the conclusion that the only 'solution' is to write
some code that automatically re-imports the subforms from the library into
the main db if they're they're newer. It's a horrible workaround though, for
a problem that shouldn't exist. I mean, libraries are supposed to provide a
means to _avoid_ duplication, not add to it!!

An explanation from MS would be fantastic... Any MS officials willing to
volunteer??

Well, unless you're an MSDN subscriber and have logged in via that website, no
one from MSFT will answer. You could open a support incident (which would cost
money) to get MSFT interaction.

Beyond that, all I can say is that Office was not designed to provide a
higher-level programming "experience". Compared to "real" programming languages,
VBA is quite limited, and isn't going to be extended. You could use classic VB
or a .NET Framework to interface with the data in the Access database. That
would provide you with more of the programming functionality you expect - but
then you'd lose the advantages working in the "native" Access environment gives
you (sub-forms easily linking to one-to-many data, for example). Only you can
judge which approach is going to cause more pain.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or reply
in the newsgroup and not by e-mail

 

[dommo]

Hi Cindy,

Yeah, I think you're right, and I should probably move over to a full
programming langauge in the long run. The problem is that I've written the
whole app in VBA under Access (it's developed into quite a big beastie over
thr last couple of years), and it'd be a big job to start again

In fact I did post the message as an MSDN subscriber (via my work MSDN
subscription), so maybe an MS official will eventually make a comment...

Thanks for your thoughts anyway.
Dom.

 

[Cindy M.]

Hi =?Utf-8?B?ZG9tbW8=?=,

In fact I did post the message as an MSDN subscriber (via my work MSDN
subscription), so maybe an MS official will eventually make a comment...

If they haven't, they probably won't. I'd escalate this over the MSDN
online-concierge, asking why you haven't gotten a reply.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail