Improving performance over the WAN

[David Mueller]

First, I do know better but I'm doing it anyway.

Second, without adding any technology (MS SQL, TS, ...) is there anything I
can do to optimize MS Access for use over the WAN? If I can tweak one,
single, solitary, obscure, hardly-ever-heard-of-and-maybe-not-even-published
setting I'll feel better about the whole situation.

Thanks,
David

 

[Rick Brandt]

First, I do know better but I'm doing it anyway.

Second, without adding any technology (MS SQL, TS, ...) is there
anything I can do to optimize MS Access for use over the WAN? If I
can tweak one, single, solitary, obscure,
hardly-ever-heard-of-and-maybe-not-even-published setting I'll feel
better about the whole situation.

Thanks,
David

You can make the entire file easy to replace for when it gets trashed.
Otherwise all you can do is make changes such that you are pulling the
absolute least amount of data and writing to disk as infrequently as
possible.

 

[Tony Toews]

First, I do know better but I'm doing it anyway.

Second, without adding any technology (MS SQL, TS, ...)
Ahhh.....

is there anything I
can do to optimize MS Access for use over the WAN? If I can tweak one,
single, solitary, obscure, hardly-ever-heard-of-and-maybe-not-even-published
setting I'll feel better about the whole situation.

Put the MDB in the root of the share. Do not put it three folders
down. Also use an eight character or less file name.

That is \\Server\Database\Backend.mdb is preferred to
\\Server\This project folder\that subfolder\yet another
subfolder\Project System backend.mdb.

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 Toews]

Second, without adding any technology (MS SQL, TS, ...) is there anything I
can do to optimize MS Access for use over the WAN? If I can tweak one,
single, solitary, obscure, hardly-ever-heard-of-and-maybe-not-even-published
setting I'll feel better about the whole situation.

Note that you are at a very high risk of corruption. Best wishes.

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

 

[Chris Mills]

Because Access and WAN are so difficult to say in the same sentence, I wonder
who if anyone has actually tried it to any significant extent. Performance is
predictable, I'm not really sure about WAN reliability these days.

So, we need to ENCOURAGE David, better him than me, and hopefully he'll report
back!

<g>

 

[Mikal via AccessMonster.com]

I don't know what to tell you to do to optimize performance over the WAN, but
I'll give you my own experience. We have about 9MB of data shared among 5
users. I started the DB 3 years ago and had very little knowledge. It shows.
The DB is very far from perfect, but it is useful nonetheless. It is about
150 miles from here to the shared drive and back. Prior to our IT folks
getting the Citrix server stable (there was evidently a learning curve or
else low demand for the service, I don't know which) I could count on finding
a corrupt BE about every month or two. About two or three times a year it
couldn't be repaired and had to be restored from backup files which I try to
remember to make every day. When the network was running smoothly,
performance was slow but acceptable. When the network was marginal, I and my
users wanted to pull out our hair. On the whole, having the shared DB was
better than not having it by a pretty wide margin. Other than that, I only
have two pieces of advice:

1. Agitate for TS or Citrix

2. Make your backups like they vote in Chicago: early and often.

HTH

Mike

 

[Tony Toews]

I don't know what to tell you to do to optimize performance over the WAN, but
I'll give you my own experience. We have about 9MB of data shared among 5
users. I started the DB 3 years ago and had very little knowledge. It shows.
The DB is very far from perfect, but it is useful nonetheless. It is about
150 miles from here to the shared drive and back. Prior to our IT folks
getting the Citrix server stable (there was evidently a learning curve or
else low demand for the service, I don't know which) I could count on finding
a corrupt BE about every month or two. About two or three times a year it
couldn't be repaired and had to be restored from backup files which I try to
remember to make every day. When the network was running smoothly,
performance was slow but acceptable. When the network was marginal, I and my
users wanted to pull out our hair. On the whole, having the shared DB was
better than not having it by a pretty wide margin. Other than that, I only
have two pieces of advice:

1. Agitate for TS or Citrix

2. Make your backups like they vote in Chicago: early and often.

Excellent posting. Thanks for that. But you missed one detail.

I thought Chicago also voted from cemeteries?

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

 

[Mikal via AccessMonster.com]

Excellent posting. Thanks for that. But you missed one detail.

I thought Chicago also voted from cemeteries?

Tony

Thank you for the compliment. Not being from Chicago, I have only heard the
rumors. I am, however from Louisiana and would like to offer this paraphrase
from former governor Earl K. Long: Do you mean to say you would
disenfranchise the dead? You would actually deny a person's God-given right
to vote just because some P***ant doctor scratched his name on a piece of
paper?!?

Mike

 

[85ascMcLaren]

If you cannot put the MDB in the root folder, does the same performance
increase come from assigning the root of a mapped letter to the database
location ?

Example: map p: \\xxx\yyy\zzz\abc.mdb

Then relinking the tables based on P:\abc.mdb

???

Jason

 

[Tony Toews [MVP]]

If you cannot put the MDB in the root folder, does the same performance
increase come from assigning the root of a mapped letter to the database
location ?

Example: map p: \\xxx\yyy\zzz\abc.mdb

Then relinking the tables based on P:\abc.mdb

I have no idea. That's something I'd have to test.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

 

[David W. Fenton]

=?Utf-8?B?ODVhc2NNY0xhcmVu?=

If you cannot put the MDB in the root folder, does the same
performance increase come from assigning the root of a mapped
letter to the database location ?

Example: map p: \\xxx\yyy\zzz\abc.mdb

Then relinking the tables based on P:\abc.mdb

No. Mapped drive letters are resolved behind the scenes to the UNC
path, so that's not a way to avoid the problem at all. It just hides
it.

Mapped drives are an artifact of the past. Start getting used to not
using them. I stopped using them in 1998,