Combining Multiple Access Applications

  • Thread starter Thread starter LisaB
  • Start date Start date
L

LisaB

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.
 
LisaB said:
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.
Click to expand...

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.
 
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.
 
Back
Top