Use the lowest common version. That is, use 03. Users with 07 can run 03
apps, but users with 03 cannot run 07 apps.
Now, to clarify and expand on Jerry's comments.
To fully understand what he was saying, you have to be clear on split
databases. That is, your data will reside in Back End (BE) mdb files. These
files need to be on a server where all users who will use that data have
read/write/delete permissions.
You application (FE) mdb will not contain any data (with some minor
exceptions), but will Link to the data in the BE. You can link to multiple
BE databases. This is a key point of Jerry's remarks. That is, you have
several different business units to serve. Each of those units will have
their own business rules and data requirements. Each of the units should
have their own BE that contains data that only their unit uses. However,
there are some data which all units will need. Maybe all units need employee
information. Granted, they have different employees, but the data for each
is the same. Rather than carrying employee info in each unit's BE, it makes
since to put all employee data in a BE and locate that on a server where all
users, regardless of business unit, have permissions.
So, evaluate the business rules and data requirements for all units and
where there is a common need, put those data in the common BE. Where the data
are unique to a unit, put them in a BE specific to that unit.
Another advantage to this structure is that if production's BE is having
problems and needs to go off line, the other units can continue to work.
Now, as to the FE applications, what to include. Well, you could have one
big app that satisfies all users in all departments. This is not necessarily
a bad idea; however, security sometimes dictates they be separated. For
example, HR and Payroll may not want everyone having access to their
application. Accounting may have similar feelings abount the GL data. So,
it may be necessary to provide functionality on a unit basis. And again,
there may be some commonality that all users need. You may consider a "core"
application, and unit specific applications. be delivered to users.
The issue here though is users may complain about having to launch separate
apps to get their work done. There is a way you can deliver various versions
of an application all built off the same basic model that contains
everything. That would be using Visual SourceSafe. Used correctly, you can
create a baseline model that contains all the functionality you will deliver.
Then, you build various versions based on that model to deliver to different
units.
This makes your life easier because now you only have to make a modification
in the baseline model and regenerate new versions of the specific
applications from that.
So, to start. Close Access.
Use a pencil and paper (make sure you have lots of erasers), or Visio, or
Word, or any tool you like EXCEPI Access.
Define your business and data requirements.
Map your data and analyze who will need it and how it will be used.
Design your tables, relationships, fields, and indexes
Describe the functionality of the application.
Identify the userrs of each business function the application will support.
Define what functionality will be included in each application version.
Now, get 'er done.
A follow up point on security.
2007 has droped the group level security, so there is no longer any security
imposed externally. You will have to roll your own security system if you
want to have multiple users using the same application version who have
different access rights.
One