Changes to one database effects all Access databases?

K

Ken Ivins

I am working on a pre-existing database and making a bunch of changes. The
client has a number of databases. One of the other databases is now working
slower on one computer. The client said that when the last designer did
changes to one database it would effect others as well. He would then tinker
and it would all work well.

This sounds like a coincidence to me but I have heard of stranger things, so
I thought I would post something and see if someone has an idea of what be
going on and how to fix it.

Thanks,
Ken
 
A

Albert D.Kallal

I am not aware of this problem.

On the other hand, are you talking about a multi-user environment?

Further, there are a number of performance issues that can result after you
edit, or modify a database (typically, this is the track-name autocorrect
option trying to do its stuff).

So, if you are running a mutli-user system, then you MUST split the
database, and you MUST provide EACH workstation a copy of the front end, and
that front end should be a mde.

For a list of performances got-ya's to check over...check out the following
list:

http://www.granite.ab.ca/access/performancefaq.htm
 
K

Ken Ivins

Dear Albert,

Thanks for the information. That link is very helpful.

It is a multi user environment. It is split with the front end (forms etc.)
is on each machine with a table link to the server. I am working with Access
2003 but they are working in 2000. So when I go to make it a .mde and am
told it can not do this. Can it be done in 2000 to a 2000 file?

This link is great. I found some real helpful ideas here to smooth things
out. This database has some real performance issues. I plan on turning off
the auto correct to see how well this works.

The latest thing that is slow on the other database (one I have never
touched) is when they try and use the find feature to locate a record on the
file stored on the server. It was working fine last week and now (after I
just changed my database) it can take up to 6 minutes. This only happens on
one of the machines in a 5 user and one dedicated server environment. I
believe it is a networking issue but not a 100% sure. One of those real
mysteries.

Thanks again for your help.
Ken



"Albert D.Kallal"
 
A

Albert D.Kallal

Ken Ivins said:
I am working with Access 2003 but they are working in 2000. So when I go
to make it a .mde and am told it can not do this. Can it be done in 2000
to a 2000 file?

No, you must have access 2003 on each machine to do this. So, you will have
to stick with using a mdb, and a2000 format.

If the none of the users are relying on other vendors, or other a2000
databases, then you could dump a2000, and go with the a2003 runtime.

Further, if your users are using a2000, then you REALLY need to do a
de-compile, and then re-compile the mdb in a2000 BEFORE you distribute this
mdb.
The latest thing that is slow on the other database (one I have never
touched) is when they try and use the find feature to locate a record on
the file stored on the server. It was working fine last week and now
(after I just changed my database) it can take up to 6 minutes.

It is very possible a networking issue, or security was changed. Do note,
you do want to keep a persistent connection open from the front end to the
back end (this is mentioned in that Tony performance faq). This may not fix
the above problem...but it REALLY help performance in many cases.
 
R

Rick Brandt

Albert said:
No, you must have access 2003 on each machine to do this. So, you
will have to stick with using a mdb, and a2000 format.

If the none of the users are relying on other vendors, or other a2000
databases, then you could dump a2000, and go with the a2003 runtime.

Further, if your users are using a2000, then you REALLY need to do a
de-compile, and then re-compile the mdb in a2000 BEFORE you
distribute this mdb.

I would add... If you are developing Access apps for other people to use and you
have no control over what version of Access they use then you need to open the
wallet and acquire ALL of the versions. It is silly to develop in a version
that is higher than what your users have for the reasons you have already
encountered plus the fact that you can never really adequately test an app if
you are running it in a different version than the end-users.
 
Top