S.Hoitinga said:
I feel a bit like a moron too.
Could you please explain what you're on about when you talk about
frontend and backend databases?
Does it mean that you have a database for the end users to enter data
in (front end) and a collector database (back end)
that gets all the data from different users.
Not exactly, but you're close. When sharing a database application,
especially an Access application, it is convenient, prudent, and
efficient to "split" the database into two separate MDB files. One,
commonly called the "front end", contains all the forms, reports,
queries, macros, and modules, as well as any other user-interface
elements. The other, commonly called the "back end", contains only the
tables, nothing else.
A single copy of the back end is stored on a server somewhere, and each
user is given his own copy of the front end, to be stored (usually) on
his own workstation. Each copy of the front-end is linked to the
back-end, so that the tables that actually reside in the back-end appear
in the front-end as linked tables. A front-end may also contain a few
local tables used for work storage or for configuration, but not for any
data that is to be shared among the various users.
The front-end thus constitutes the user interface and programming part
of the database application, while the back-end constitutes the shared
data store. By dividing or "splitting" the application this way, the
developer
(a) minimizes network traffic, since none of the user-interface
elements have to be brought across from the server,
(b) minimizes the risk of corruption, since only data -- no design
elements -- travel across the network, and no two users can be updating
the design of any object or of the VB project at the same time,
(c) prevents one user's changes to any of the design elements from
affecting any other user,
(d) can, if necessary, customize the application for one particular
user without affecting any others, and
(e) can distribute updates to the front-end without affecting the
back-end data store or putting it temporarily out of commission. This
is a great convenience, since once the data design has stabilized the
back-end rarely undergoes design changes.
Why isn't creating usergroups with permissionlevels not enough?
As you see, setting user-level permissions is a separate matter, and not
really related to the benefits of splitting a shared database
application.
For more information about splitting Accessa databases, I suggest you
look at Tony Toews' page on the subject:
http://www.granite.ab.ca/access/splitapp/index.htm