Microsoft Access Secrets?

[rmccall]

I built a number of Microsoft Access programs in Access 2000. We are
trying to use them now in Access 2003.

I have split the programs and configured them as SHARED in edit mode.
I have tried no locks and edit modes.

I set the frontend on the workstation and the backend on the server
drive that is shared.

What is the problem with them still freezing when multiple users try to
do data entry.

Very frustrated with this application as this never happened to me with
Lotus Approach.

If there is anyone out there that can help me with this I would really
appreciate your expertize.

[Keith W]

<rm*****@dss.state.sc.us> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

I set the frontend on the workstation and the backend on the server
drive that is shared.

What is the problem with them still freezing when multiple users try to
do data entry.

Does each user have their own copy of the FE?

Keith.
www.keithwilby.com

[rmccall]

Yes. I have set up a separate folder on their C drive and copied the
frontend on each work station.

[Fred Boer]

Do users have *full* (read, write, delete) permissions for the folder in
which the back end is stored?

HTH
Fred Boer

<rm*****@dss.state.sc.us> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

I built a number of Microsoft Access programs in Access 2000. We are
trying to use them now in Access 2003.

I have split the programs and configured them as SHARED in edit mode.
I have tried no locks and edit modes.

I set the frontend on the workstation and the backend on the server
drive that is shared.

What is the problem with them still freezing when multiple users try to
do data entry.

Very frustrated with this application as this never happened to me with
Lotus Approach.

If there is anyone out there that can help me with this I would really
appreciate your expertize.

[rmccall]

Yes.

[Larry Linson]

Are you keeping a connection to the server open all the time?

Have you indexed the tables, and built your queries to take advantage of
those indexes, retrieving just the records you need?

Interesting -- data entry (of new records) is not where I'd expect to find a
problem. It would be updates of existing records that I would ordinarily
suspect.

Did you look at the performance tips and hints at Tony Toews' site
http://www.granite.ab.ca/accsmstr.htm? That's the best collection of
information and links on the subject that I know about.

Larry Linson
Microsoft Access MVP

<rm*****@dss.state.sc.us> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

I built a number of Microsoft Access programs in Access 2000. We are
trying to use them now in Access 2003.

I have split the programs and configured them as SHARED in edit mode.
I have tried no locks and edit modes.

I set the frontend on the workstation and the backend on the server
drive that is shared.

What is the problem with them still freezing when multiple users try to
do data entry.

Very frustrated with this application as this never happened to me with
Lotus Approach.

If there is anyone out there that can help me with this I would really
appreciate your expertize.

[Trevor Best]

rm*****@dss.state.sc.us wrote:

I built a number of Microsoft Access programs in Access 2000. We are
trying to use them now in Access 2003.

I have split the programs and configured them as SHARED in edit mode.
I have tried no locks and edit modes.

I set the frontend on the workstation and the backend on the server
drive that is shared.

What is the problem with them still freezing when multiple users try to
do data entry.

Very frustrated with this application as this never happened to me with
Lotus Approach.

If there is anyone out there that can help me with this I would really
appreciate your expertize.

Was the 2000 version split? If so did this performance hit occur there
as well?

[summerwind]

I had a problem similar to this once where I was picking up on someone
else's work.

I found that the problem in my case was the connection to the data and
that all of the forms etc in the app were bound to underlying tables.

Solution was to use unbound forms and rewrite considerable amounts of
code so that minimum data was transferred over the network at any one
time.

After I had finished I concluded it would have been quicker to re-write
the whole app!!!

[David W. Fenton]

"summerwind" <su*************@btinternet.com> wrote in
news:11*********************@g44g2000cwa.googlegro ups.com:

I had a problem similar to this once where I was picking up on
someone else's work.

I found that the problem in my case was the connection to the data
and that all of the forms etc in the app were bound to underlying
tables.

Solution was to use unbound forms and rewrite considerable amounts
of code so that minimum data was transferred over the network at
any one time.

After I had finished I concluded it would have been quicker to
re-write the whole app!!!

How idiotic.

Binding the forms to filtered recordsets of one or few records would
probably have gotten you 99.99% of the performance that going
entirely unbound got you, without losing all the events that bound
forms/controls have by default (and which need to be replicated in
some way in an unbound form).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc