Slow MS Access DB over WAN

  • Thread starter Thread starter Dan_M
  • Start date Start date
D

Dan_M

We have an MS Access 2000 application run over a WAN (wintel server). It is
built with a frontend on the users machine and backend on the shared drive of
the server. The shared drive is near the root (2 folders away), is accessed
by 50 or less people running Access 2000 to 2003 over the WAN, the backend is
less than 50 MBs in size, and has only 150,000 records in it. The DB runs
exceptionally slow! Just opening forms or reports can take two minutes each!
Very frustrating! We have followed Microsoft's recommendations for building
this thing but is so slow that it is not very useable. Does anybody have any
ideas to make this DB speed up and become more useable?
 
"...is accessed by 50 or less people"

Are you talking about "50 or less people" simultaneously?
 
missinglinq via AccessMonster.com said:
"...is accessed by 50 or less people"

Are you talking about "50 or less people"
simultaneously?

Actually, that's immaterial in this situation -- the key problem is _WAN_,
as jahoobob pointed out, not the number of users.

Larry Linson
Microsoft Access MVP
 
you're a mother ****ing dipshit kid

Access works _GREAT_ over a wan.
it is the MDB format that sucks a big fat donkey dick

Access Data Projects work great over a WAN

nobody should be using MDB for anything; it has not been the
reccomended format for a decade
 
Larry

stop spreading mis-information. The problme is not WAN, the problem is
MDB

ADP works GREAR over a WAN, VPN, WIreless-- anything

STFU and lose the training wheels you goddamn loser
 
move the data to SQL Server and then do this in MS Access

FILE, NEW, PROJECT EXISTING DATA
 
Thanks for the link...I'll check it out.
I don't think there is much hope as Access just isn't made for use over a WAN.
Albert Kallal showed that a form that loads in 4 seconds on a LAN will take
over 6 MINUTES to load over a WAN.
Go here for his discussion:
http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html
We have an MS Access 2000 application run over a WAN (wintel server). It is
built with a frontend on the users machine and backend on the shared drive of
[quoted text clipped - 5 lines]
this thing but is so slow that it is not very useable. Does anybody have any
ideas to make this DB speed up and become more useable?
 
we're going to look into this option more after reading this and similar
postings. Your message got cut off, care to re-post?
move the data to SQL Server and then do this in MS Access

FILE, NEW, PROJECT EXISTING DATA
We have an MS Access 2000 application run over a WAN (wintel server). It is
built with a frontend on the users machine and backend on the shared drive of
[quoted text clipped - 5 lines]
this thing but is so slow that it is not very useable. Does anybody have any
ideas to make this DB speed up and become more useable?
 
Dan_M said:
We have an MS Access 2000 application run over a WAN (wintel server). It is
built with a frontend on the users machine and backend on the shared drive of
[quoted text clipped - 5 lines]
this thing but is so slow that it is not very useable. Does anybody have any
ideas to make this DB speed up and become more useable?
we're going to look into this option more after reading this and similar
postings. Your message got cut off, care to re-post?

1) Note that this person is really A a r o n K e m p f and that he
is not an employee of Microsoft.

2) Aaron's answer is almost always ADPs no matter what the question
is.

Access does not do well on a WAN. As others have pointed out your
options are to use Terminal Server or SQL Server or equivalent for the
data.

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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
As others have pointed out your
options are to use Terminal Server or SQL Server or equivalent for
the data.

And the absolutely easiest thing to do is to host it on Terminal
Server, since that won't require any changes to the application
itself.

It's also much cheaper than investing in re-architecting your app to
work with a SQL Server back end.

And it makes administration *very* easy, as everything is in one
place.
 
Back
Top