I have a question about combining multiple Access Applications into one
Access Application.

1. I have a client who has 3 separate MSAccess Applications. Each with its
own forms, queries, reports, tables, and modules. These applications were
developed at different times with different programmers.

2. The client wants these three applications to be combined into one
seamless application or program interface.

3. After combined, each application will have some tables in common with
the others
_______________________________________________________________________

My DILEMMA - There will be over 170 queries and over 160 forms making it
difficult for anyone who comes onboard afterward to figure it all out and do
upgrades and technical support.


DOES ANYONE HAVE A BETTER IDEA?

I feel your pain but 170 queries is not really that much...
I work with an app that has a total of 2532. 608 of which
r Action queries. the only thin I could say is
documentation.

>-----Original Message-----
>I have a question about combining multiple Access
Applications into one
>Access Application.
>
>1. I have a client who has 3 separate MSAccess
Applications. Each with its
>own forms, queries, reports, tables, and modules. These
applications were
>developed at different times with different programmers.
>
>2. The client wants these three applications to be
combined into one
>seamless application or program interface.
>
>3. After combined, each application will have some
tables in common with
>the others
>__________________________________________________________
_____________
>
>My DILEMMA - There will be over 170 queries and over 160
forms making it
>difficult for anyone who comes onboard afterward to
figure it all out and do
>upgrades and technical support.
>
>
>DOES ANYONE HAVE A BETTER IDEA?
>
>
>.
>

"LisaB" <lbagley(ReTHis)@mayatech.com> wrote in message
news:(E-Mail Removed)
> I have a question about combining multiple Access Applications into
> one Access Application.
>
> 1. I have a client who has 3 separate MSAccess Applications. Each
> with its own forms, queries, reports, tables, and modules. These
> applications were developed at different times with different
> programmers.
>
> 2. The client wants these three applications to be combined into one
> seamless application or program interface.
>
> 3. After combined, each application will have some tables in common
> with the others
>
_______________________________________________________________________
>
> My DILEMMA - There will be over 170 queries and over 160 forms
> making it difficult for anyone who comes onboard afterward to figure
> it all out and do upgrades and technical support.

170 queries is not so unusual. 160 forms is a lot, but not absurd.
Still, here are a couple of ways to keep it manageable:

(1) If you're using Access 2000 or later, use the Groups feature of the
database container window to group together the objects that are
logically associated with each other.

(2) Use naming conventions for objects, such that the name of an object
helps to identify its functional grouping.

(3) This is a rather more elaborate scheme: have one back-end database
and multiple front-end databases, one for each functional group. Either
use a fourth, "dispatcher" front-end to select and open the appropriate
front-end, or use a small VB program for the purpose, or just let each
front-end provide the facility to switch to one of the others.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

I have an app with 690 queries (that is how many are saved anyway), 30,000
lines of code, etc.. I broke it down into 10 different library MDBs that
more or less group certain functionality together. There is a main MDB that
has references to the others....it has minimal functionality of it
own...most is contained in the libraries.

There are some drawbacks to this approach...the biggest being that you must
compile all of the MDBs together and distribute them as a set (I've
automated that process). Also, installation is a little trickier. But I've
overcome that too. In any case, I've found this a lot easier to maintain as
I frequently add new functionality...I just add it to whatever library makes
the most sense.

--
Paul Overway
Logico Solutions, LLC
www.logico-solutions.com


"LisaB" <lbagley(ReTHis)@mayatech.com> wrote in message
news:(E-Mail Removed)...
> I have a question about combining multiple Access Applications into one
> Access Application.
>
> 1. I have a client who has 3 separate MSAccess Applications. Each with
its
> own forms, queries, reports, tables, and modules. These applications were
> developed at different times with different programmers.
>
> 2. The client wants these three applications to be combined into one
> seamless application or program interface.
>
> 3. After combined, each application will have some tables in common with
> the others
> _______________________________________________________________________
>
> My DILEMMA - There will be over 170 queries and over 160 forms making it
> difficult for anyone who comes onboard afterward to figure it all out and
do
> upgrades and technical support.
>
>
> DOES ANYONE HAVE A BETTER IDEA?
>
>