|
|
|
date: Wed, 3 Oct 2007 11:11:01 -0700,
group: microsoft.public.access.multiuser
back
Re: ACCESS Performance
Make an Access application for
adding records
And a different Access application for
reading records
You can put both applications into the one mdb,
just don't try to make one form that does everything.
One form that does adding,reading,searching,editing
is a lot more difficult with 150 users than it is with 2
users.
(david)
"Lynn" wrote in message
news:91456482-75AA-4434-8FA8-D9595760E855@microsoft.com...
>I need a quick & cheap short term solution for an existing ACCESS db.
> However, I am concerned about ACCESS performance.
> Could you review below and offer suggestions. Thank you.
>
> Background:
> Stores survey data. They take surveys 1 or 2 a year for 250 employees.
> They have only surv
> For the first and only survey, they loaded data from an Excel file & have
> only made minor chgs via tables.
>
> Current DB: mdb with tables, queries, reports that only 2 Users access
> data is not normalized. They have a separate table for
> each
> survey category. One table has 104 fields for each
> survey topic.
> Data is stored by network ID.
>
>
> Proposed: Since I need a quick, cheap solution ....
> Don't normalize data.
> Create a FE with bound forms- 1 for each survey category. This means
> that
> one form will have 104 fields on it.
> Move all queries, report to the FE. Place the FE on all 150 desktops.
> This means that rollout or upgrades will be painful.
> I believe I could also add code to limit the number of concurrent users by
> checking the ldb file.
date: Fri, 5 Oct 2007 12:22:45 +1000
author: david
Re: ACCESS Performance
"Lynn" wrote in message
news:91456482-75AA-4434-8FA8-D9595760E855@microsoft.com...
> Create a FE with bound forms- 1 for each survey category. This means
> that
> one form will have 104 fields on it.
> Move all queries, report to the FE. Place the FE on all 150 desktops.
> This means that rollout or upgrades will be painful.
> I believe I could also add code to limit the number of concurrent users by
> checking the ldb file.
The problem is that you going to have to train these users. And, further,
you going have to take CONSIDERABLE extra effort that each user does not
overwrite other persons data.
And, furthermore, you have make sure these people are well versed in using
ms-access also.
I suppose you *can* make the application "hide" themes-access interface,
build
some VERY user friendly forms. And, then throw on top a good mechanism to
distinguish the data entered by each person.
Remember, ms-access is a development tool for software. When you go to the
motor vehicle department, the trained operator is does not turn over the
computer to the user..and let them run the motor vehicles software system.
So, ms-access is NOT well suited to a kiosk type system in which un-trained
users would use ms-access to register a car, or this case can fire up
application they never seen before, and are not familiar with.
and, you great pains will have to be taken to separate each persons data
entry. Remember, normally, you WANT all users of the application to view,
and edit, and find data in the system (just like the motor vehicle
system...anyone of the office clerks using that software SHOULD be able to
find, and bring up a car for example.
You talking about a system in which EACH user is not trained in ms-access,
and EACH user is to have their own data separated from either other. This
design model is not what ms-access was built to do.
For a company wide survey type system, it seems to be that building a simply
web based form would do the trick here.
You can use ms-access for this task, but you need to well address the above
problems.
If you don't address the user interface, training, ease of use, and things
like keeping records seperate, then your project will be nothing but a
exercise in frustration...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
date: Thu, 4 Oct 2007 23:02:48 -0600
author: Albert D. Kallal
|
|
