Poor performance over WiFi

[mounty76]

Hello!

I have a split DB with the backend on a server, FE is local on computer.

The DB runs slow when connected over WiFi yet when using an ethernet cable to connect to the network it runs fast? Any ideas?

The wireless network is a new high end Cisco network with WiFi 7 access points, my laptop is getting PHY speeds of 1200mbps and latency to the file server is approx 3ms.

Many thanks for any ideas!!

 

[Minty]

WiFi isn't good at maintaining the type of connection Access uses (SMB Protocol), so there will be a lot of behind the scenes connection renegotiation. Most WiFi setups are also designed to save power out of the box, so continually scale back things silently as well.

This ultimately can lead to corruption where something breaks the connection mid transaction.

Wired connection for the WIN with Access I'm afraid.

 

[mounty76]

Thanks for the info Minty, much appreciated

 

[theDBguy]

Thanks for the info Minty, much appreciated

You might be able to get away with using WiFi if the BE is SQL Server. Just a thought...

 

[The_Doc_Man]

Just as a word of warning... Windows File and Printer Sharing Protocol is what Windows calls it, but in general networking terms it is Server Message Block, or SMB. Access ABSOLUTELY requires SMB support. Some time ago two new versions of SMB have come out and are better at a lot of things - but SMB is still a TCP-family protocol that uses a sequence counter to maintain continuity and to detect certain types of interference.

If you EVER have a Wi-Fi drop and you don't have "Session Reconnect" options enabled, your database runs the risk of being corrupted badly - to the point of non-recovery. Further, if you have a relatively competent IT staff, your servers will ALL be locked down the prevent "reconnect" actions, because that is a common hacking method.

SQL Server uses OLDB protocol which has different continuity requirements and thus CAN survive a brief network outage. Access is easier to use for small shops but the bigger you get, the better you would be to eventually go to an active back-end server. Stay with Access BE files as long as you can for ease of management.

To be honest, Ethernet, though it is more reliable because it is "hard wired" between the two end points, can also suffer a network drop. However, in such cases it is because of a physical device failure and therefore is of far lower odds. Overloading an Ethernet so that it is more than about 30% saturated is another way to damage your network efficiency.

 

[mounty76]

Thanks guys, all good points but unfortunately our old NAS drive supports none of that . Looking to potentially run it on a remote PC linked directly to the network

 

[Pat Hartman]

Looking to potentially run it on a remote PC linked directly to the network

Look into using a different platform than Access in that case.

If you stick with the Access FE, Citrix and Remote Desktop are viable options for accessing Access applications remotely but you need to have the infrastructure to run the Citrix or RD server on your LAN. You can try using a VPN but it will be slow as molasses if the BE is Jet/ACE. You will have better performance in this configuration if the BE is SQL Server. Citrix and RD solve the problem because all the data transfer is within the LAN and doesn't have to travel over the internet so you don't need to upsize to SQL Server, you can stay with Jet/ACE.

If you go with Azure, I think you get something like a Citrix/RD option but that comes at a price.

 

[Isaac]

This was one of the reasons why, when my career started to go in a non-Access direction a few years ago, I didn't feel as badly about it as I might have. It was getting to the point where these 2 things didn't play well together, as a broad (and accurate) generalization:
- Access back end in a network share, linked to each person's FE
- Everyone on WIFI

I thought to myself "Hmmm, that's a pretty big problem for Access, since everyone is on WIFI nowadays, especially working from home via VPNs"

Haven't, yet at least, heard of a solution other than "go back to wired", which of course, nobody's going to do as it's the year 2025 and we're not going backwards in time

 

[AccessBlaster]

You might be able to get away with using WiFi if the BE is SQL Server. Just a thought...

That’s what I had to do while working for the school district. My inventory database backend ran on a SQL Server, and the frontend was on my laptop. I accessed the BE remotely from various school sites using their Wi-Fi or a cable. It was sketchy at times, but it allowed me to update the backend in real time. At the time, I wasn't aware of other options like Citrix etc.

 

[Isaac]

Yeah I should have added ... if your back end is some other database service and not Access, you might be perfectly fine.

I guess there's other solutions too, a few years ago I used IONOS virtual desktops to enable a client to utilize some sweet Access/Excel/Google Sheets/VBA processes. Which also taught me something - these people who mass sell on Amazon & Ebay, they go through a lot to try to automate it. I spent years off and on doing projects for a guy who mass sells on Amazon and Ebay. The ways he had to slice and dice data, downloads, manipulation then uploads...was amazing

But for the typical CORPORATE environment, where there's network shares and people on VPN's and wifi - and you have no authority or ability to 'decide' to use Citrix or VMWare or etc., you're kinda screwed if you're trying to use an Access BE

 

[The_Doc_Man]

Thanks guys, all good points but unfortunately our old NAS drive supports none of that . Looking to potentially run it on a remote PC linked directly to the network

IF the NAS disk is less than 10 years old, and if you have a way to look it up, check whether it supports SMB protocols. A LOT of NAS drives have been created to run OK with Windows, which uses SMB. If you can get a copy of the user's manual for that NAS device, before you abandon it, you might be pleasantly surprised that it supports Windows File and Printer sharing protocol - which is SMB.

 

[Gasman]

My first NAS boxes only support SMB1. DLink DNS-323

 

[The_Doc_Man]

My first NAS boxes only support SMB1. DLink DNS-323

Yes, but SMB-1 is adequate. The SMB-2 and SMB-3 versions deal with buffering optimization but SMB-1 covers the basics that you need for Access.

 

[amorosik]

Hello!

I have a split DB with the backend on a server, FE is local on computer.

The DB runs slow when connected over WiFi yet when using an ethernet cable to connect to the network it runs fast? Any ideas?

The wireless network is a new high end Cisco network with WiFi 7 access points, my laptop is getting PHY speeds of 1200mbps and latency to the file server is approx 3ms.

Many thanks for any ideas!!

First of all, I would personally perform some measurements on the amount of data passing via wifi lan, in order to understand if the amount of data is the problem or not
If you see 50 Mbit/sec passing for 6 seconds, it means that the PC is calling data for about 30 Megabytes, and passing them via radio is inevitably less efficient than the cable
But even if a client is connected to the db server via radio, in my opinion, it should be usable
I mean, the problem is the 30 Mbytes called, not the 50 Mbit/sec radio route

 

[mounty76]

Thanks everyone for your input, much appreciated. My IT guy said a virtual PC will do the job, he said its the younger brother of Citrix and that Citrix is an overkill for our needs

 

[The_Doc_Man]

If by "virtual PC" your IT guy meant something in a VMWare environment, that is not a bad solution. In fact, it is probably a very economical solution. An Access back-end running on a virtual PC like that will have almost no CPU load when the Access app isn't active, and the only REAL load will be file management when the app IS active.

I ran an Access app for the U.S. Navy in exactly that situation and it comfortably handled a 40-user group of whom maybe 4 to 8 were ever on at the same time against a 600k records DB, probably about 200-300 Mb of total data when freshly compacted, and it wasn't badly bogged down except on Friday afternoons when everybody wanted to clear their desks for the weekend.

IF your IT guys are worried about controlling user access to that setup, you can use Windows Group Identifiers so that if you add a new user, all you have to do is grant the user that identifier and you don't have to diddle around permissions for however many files and folders are involved. Very efficient if you do it that way, and consistent with Windows advisories on setting up file sharing.

 

[mounty76]

Great, thanks Doc Man, that is exactly what he is thinking, should do the trick nicely