Speed improvement w/2003 + MDE conversion?

E

el zorro

I have a database that is shared, sometines concurrently.
by about 8 users. The back end, which expands to about 39
MB before being compressed back to around 20 MB on a
weekly basis, is on a Windows server. I'm starting to
hear grumblings about how slowly the application runs. I
claim it's a server issue, not an Access problem.
However, they are all running Access 2000 front ends.
Would it help speed things up if they upgraded to Access
2003, and I converted their Front Ends to MDE files?
 
A

Albert D. Kallal

Would it help speed things up if they upgraded to Access

As you know, most "next" versions of software as general rule runs slower,
and takes more memory, more disk space then the previous version. I think
this rule has been true for about 20 or more years. So, most of the time,
upgrading will NOT improve speed.

When is the last time you upgraded ANY software, and that new software used
less memory, and ran faster then the previous version? (I am hard pressed to
remember when this happens!!.

However, I will say that 2003 does seem to be a lot more stable then is
a2000, and I like some of the new features like themed controls.
and I converted their Front Ends to MDE files?

We are to assume that you are talking about placing a mde on each computer.
Yes, this is a very good idea. As a general rule, a mde does run a bit
better then does a mdb. However, the mde generally does NOT fix performance
problems. However, the mde is MORE stable, and cannot become un-compiled
like a mdb can. When that mdb becomes un-compiled, then you can get long
application load times, and things most certainly can get sluggish. A mde
cannot become un-compiled. Further, the mde also ignores the track-name auto
correct issue, which again you should disable. Since there is a good half
dozen reasons and advantages to run mde's over mdb files, then you should.
For example, your users thus can't modify the mde, and you also are FORCED
to distribute a version where you KNOW the code compiles. These two reasons
alone should sell you on this concept.

As far as improving performance, you don't mention if the system runs ok
with 2 users, but then slows down as you move up to 8 users. I mean, if the
system don't work well with 2 users...how can you expect it to run well with
8, or 10 users? So, after how many users does the system slow down?

The following is a excellent check list of things you need to check to make
sure you are getting maximum performance out of your network, and your
setup. The #1 trick here is to keep a persistent connection open from the
front end on each computer to the back end. Try this first. The rest of the
list of things to check is here:

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

So, make sure EACH workstation gets a Front end that is placed on EACH
workstation. And, as mentioned, preferably this should be a mde.

Then, try the persistent connection trick.

If after doing all of the above in the above list, you still have
performance problems, then the next steps will actually mean you need to
start looking at your designs, as that also could be the problem with
performance. If you only got 5, to 8 users, and very small data tables in
the 75,000 record range, and say perhaps 30-40 related tables, then form
load times should on average be only about 1 second, and users should not
experience any serous kinds of delay during regular use.
 
E

el zorro

THanks for the excellent response! Yes, each workstation
has the FE, and the BE sits on a Windows server. I thnk
the speed issue is primarily with the sever and/or the
link to the server (and not the number of concurrent
users or the design of the database itseld) because when
I move the BE to my desktop for testing, it's fast. WHen
I put it on the Server, it crawls.

My problem in solving this speed issue is somewhat
political in nature. The hardware configuration is
determined by the Tech Services guy, and I have been
unable to convinve him that the server and/or the
connection he's using to store the BE is too slow-- he
responds that Access is a low grade application used by
housewives to store their recipes. So, I need to try
every trick I can from the programming end to address the
speed issue. I'll suggest we upgrate the users to 2003,
then give them MDE's.

Thanks again!
 
A

Albert D. Kallal

did you try the persistence connection trick? This solves 9 out of 10
cases....
 
G

Guest

you should use Access Data Projects

MDB is dead.

there are definitely some times when MDB can't even handle 30 or 50 mb of
information.

SQL Sever can
 
A

Albert D. Kallal

you should use Access Data Projects

MDB is dead.

What on earth are you talking about? We just got office 2003 with ms-access.
New features like xml support, and themed controls were added. Not to
mention the soap ad in kit for office.

Microsoft is now busy working on the next great version of ms-access, and it
show no signs of decaying at all.
there are definitely some times when MDB can't even handle 30 or 50 mb of
information.

Well, there is definitely some times when it can, and further, OFTEN JET is
MUCH faster then sql server...on the order of 40% to 200% faster in fact....

a 50 meg file is nothing for ms-access in MOST cases.

The fact that you seen one application that is bad is like saying because we
have one bad cop, we have to throw out the whole legal system, or fire all
police officers!!

Your post makes no sense at all, and can only be made by someone who lacks
any kind of professional knowledge of our industry.
 
T

Tony Toews

el zorro said:
THanks for the excellent response! Yes, each workstation
has the FE, and the BE sits on a Windows server. I thnk
the speed issue is primarily with the sever and/or the
link to the server (and not the number of concurrent
users or the design of the database itseld) because when
I move the BE to my desktop for testing, it's fast. WHen
I put it on the Server, it crawls.

As Albert has suggested visit the Access Performance FAQ page at
http://www.granite.ab.ca/access/performancefaq.htm
My problem in solving this speed issue is somewhat
political in nature. The hardware configuration is
determined by the Tech Services guy, and I have been
unable to convinve him that the server and/or the
connection he's using to store the BE is too slow.

Unless the connection is via a WAN then chances are the server and LAN
connection are fast enough.
he
responds that Access is a low grade application used by
housewives to store their recipes.

Well, here he's absolutely wrong. I have one system with 25 users.
So, I need to try
every trick I can from the programming end to address the
speed issue. I'll suggest we upgrate the users to 2003,
then give them MDE's.

A2003 won't be any faster.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Top