Access program running slow on certain computers only

Hello All,

I have an Access 2010 program that sits on a 2008 server.  Many people use the program and the way it is currently set up is that each person has a shortcut to the program (They fight me on splitting the front end from the back end).  On certain computers the program runs really really slow, to the point of screens freezing or the background of Access popping forward.

What is odd is that I remote into a computer in building 1 and from there I open the shortcut to the program.  For me it runs nicely.  The people who are having the problem with speed are in building 2.  The reason I find it odd is that I would think my computer would be the slow one since I am remoting in from my computer at home and from that computer I am accessing the program.

I did a tracert on a bunch of computers and any computer from building 1 (including the one I remote into) show <1ms while machines in building 2 show 1 to 2ms.  Could that be that much of a difference?  

Is there something I could do or run to check on the network between the two buildings (which are next to each other, not miles down the road)?

Networking is not my strongest suit so I am willing to try almost anything to get the people in building 2 faster access.


PS It does not matter how many people are actually using the Access program at the time.  It has slowed down even with 2 people on it.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

They fight me on splitting the front end from the back end
You really need to win that fight.
You're one corruption away from losing the DATA and the UI
When split, the data never winds up being corrupt, and the front end gets pushed to many workstations, so there is rarely ever the danger you will forever lose the front end or any data.

Could that be that much of a difference?
Are both building on the same subnet?
Networking is not my strongest suit
Do you know how to determine that?

If they AREN'T on the same subnet, what device is doing the routing?
I agree 100% with Nick.  Having a monolithic database is a problem waiting to happen but it isn't causing this problem.  

I would suggest posting in a network forum where people will give you the words you need to convince your network person that he has to look into the problem.

PS - once you get the app split, make sure that each user has his own personal copy of the FE.  You don't want everyone opening the same physical copy of the FE.  There are lots of simple ways of distributing the FE.  The easiest of which is to have each user run a batch file to activate the app rather than running the app itself.  The batch file copies the latest version of the FE from the safe network folder to their local C: drive and then opens it.  On most networks, the delay is imperceptible.
How is performance in file transfer.
Can you COPY the database between the server and the workstations in both buildings with equal speed.
Or is one markedly slower than the other?
How are they connected?
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
And just to pile on: I agree 100% with both Pat and Nick regarding splitting. You may find yourself in a very bad way if you don't. There's really no good reason to NOT split the database, other than to make updates easier (and with a decent updater, that's not really an issue).

Also: I had a client with a very similar issue - two buildings, and the users in one building were perfectly fine whereas the users in the second building had quite a bit of intermittent issues. Turned out to be some very old wiring and hardware. Rather than trying to update all that, they just setup a Terminal Server and ran everyone off that. Worked well, but of course there was some cost involved.
alevin16Author Commented:
Hello Everyone,

Thank you so much for all the feedback and information.  To answer one of the questions both buildings are on the same subnet, not sure about the wiring, but I do know it is not wireless.

Believe me I have tried to convince them to allow me to split the DB but for some reason they see this as evil.  I will try again with your comments in hand.

One other thing to throw into this discussion, I ran LAN Speed Test (Lite) from Totusoft on a computer in both buildings (I remoted into them).  Here are the numbers.  I do not know if the difference is significant (being that 1 ms vs. 2 ms seems really really small):

Machine in the “fast” building      Write                  Read
Time to Complete                           1.0162716              1.6824556
Bytes per second                          19,679,779        11,887,387
Bits per second                         157,448,232      95,099,096
Machine in the “slow” building      Write                  Read
Time to Complete                        2.3950350      2.5154914
Bytes per second                        8,350,608      7,950,733
Bits per second                            66,804,864      63,605,864
I don't know much about the tool you used but look at the results: 1.0162716 vs 2.3950350
Or 2.35 times as long to complete the same task on the slow side compared to the fast side.
That's likely to be highly significant.

As a test, move the db to a machine on the slow side.
Test from another machine on the slow side
Are things greatly improved?
Test from another machine on the fast side
Are things greatly degraded?

If they are, then you have your answer -- your network architecture is killing performance.
If not, we'll keep experimenting
alevin16Author Commented:
That is a great idea Nick, I am going to give it a try
alevin16Author Commented:
I spoke to the person in charge of the network for this issue emailed me this:

Alot of this has to do with distance more than anything else, "Fast" computer is going about 10 ft to the server vs "SLow" computer is going 35-40 ft to the switch in that building, then via fiber 100 ft -/+ to the switch in the server room. There will be some lag time.

Do you all think that this could explain the slowness of the slow machines?  I tested the speed again and the fast machine actually came in 10 times faster.  If this is the case what could we do to speed up the "slow" connection?

THank You!
A lot of this has to do with distance more than anything else
Any network guy who would tell you this is:
a) BS'ing
b) incompetent

Fibre moves at lightspeed
Electrons in copper about 2/3 lightspeed.

"Fast" computer is going about 10 ft to the server
99/100 the fast computers and server are on the same switch
SLow" computer is going 35-40 ft to the switch in that building, then via fiber 100 ft -/+ to the switch in the server room
And ALL the traffic from the other building needs to use that fibre.

So 'fast' machines get a 1:1 channel to the server, slow machines get 1:HoweverManyConnection to the server.  That can be bad.

The switches could be old POS (and I don't mean point of sale)
The fibre installation could be old and inefficient.
If the server is old, it could be a 100 MB card in the server
How many machines in total?

If this is really a rock-in-the-boot, then document things and kick it up to management to have the link sorted, replaced, and/or upgraded.

In order of expense
1. Add a second network card to the server and configure the network so that the slow building's traffic goes to that network card first, and not to the switch (make the server route).  May not solve the issue, though
2. Replace the switches.  If one or both are POS's things may improve
3. Replace the switches and fibre modules with better/higher speed.  More expense, likely to solve the issue
4.  Go hard and get someone in to look at the whole setup.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
alevin16Author Commented:
Hello Nick67,

This is exactly what I was looking for.  Someone who could explain what is going on in easy terms.  Thank you so much!  I am going to discuss this with the network guy and see what we can do.  if he won't budge I am going higher.

Good Luck!
You may not want to show him
A lot of this has to do with distance more than anything else
 Any network guy who would tell you this is:
 a) BS'ing
 b) incompetent

But anyone trying to insist that distance is the issue...well.
Ethernet copper has a distance limit of 93 metres from switching device to switching device (typically switch to switch or computer to switch)  That limit comes because the amount of time that a network device waits before deciding that it's packet is lost is exceeded by the travel time it takes to get to the far end.

A typical packet is ~1500 bits.
Gigabit Ethernet 1073741824 bits per second
715827.8827 packets per second.  And a packet can't make 93 metres without maybe being lost.
But we can blow 715828 of them down 92 metres of line each second.
So --rough numbers because ACKs come back on the line -- a packet takes 1/715827 of a second to travel 92 metres or less. ~66 million meters per second.

At that speed, 40 feet is going to result in how much delay?
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.