Working remotely with Access

[Wyoming]

Hello,

I have been reviewing some of the old posts related to working remotely with Access and SharePoint or Microsoft 365 were mentioned in most of them.
But my question is: assuming I don't have either SharePoint or MS Office 365 available, is there any reasonable way of accessing remotely to an Access instance?

This Access application is a split one, the back-end resides in a server that is accessible to all users in the net. The front-end has been copied to all users PCs. Now the need is, give access to the application to a user that will be working outside the network. It is understood that any remote use, if possible, will have a very poor performance but this is ok since this remote use will be just occasional. 99.9% of the use will be from within the network.

Is there any approach that could cover this need?

Thanks!

[HansV]

Can users outside the local area network login using a VPN? If so, it would be as if they were working on the local network, although with slower performance.

[Wendell]

In addition to Hans' reply, what is the backend stored in? If it's an Access back-end, then performance will definitely be slower. On the other hand, if it is a SQL Server back-end, the performance penalty won't be that bad, especially if the front-end has been optimized to use linked SQL Server tables. And another approach you might consider would be to run Remote Desktop (or one of the paid remote services) to execute the front-end on the server, and only pass the screen and keyboard/mouse updates across the web. That would likely give the best performance.

[Wyoming]

Thank you guys for your replies!

The back-end is built on MS Access so I am afraid that the performance would be really poor using the VPN approach.
The other suggestion about using a remote desktop on a front-end installed on the server sounds interesting since it could also help sort out one other issue that could arise if a user tries to connect remotely from an iMac or similar. This could be a good way to bypass this limitation.
Honestly, I am not too familiar to using Remote Desktop and its implications but I will do some research on my side since it looks like the best option I have for the moment.

Thanks again.

[CData]

I will definitely recommend remote desktop - which generically can be described as a terminal services deployment.

Classic Access (Windows not Web) requires a split database with each user having their own front end and presumes all users are on the same LAN. Attempts to put a WAN between the front & back files (tables) has been problematic. If the network is too slow the application will hang I think due to a time out style issue with handshaking. If the tables are sitting in SQL Server or SQL Azure the users must be at a fixed IP which is itself often not feasible (correction on this point welcome if my information is out of date).... The 2013 edition whereby linking to the 365 account has become more embedded makes it much more feasible - but experience has shown that when large record sets get involved it still tends to hang.

In a terminal services deployment both the front and back files are on the same LAN (potentially on the same server) and the remote user connects to a front end. Each user must still have their own front end. In this deployment the lag/handshaking between front/back(table) files is always perfect. Any lag is the user experience of their cursor moves. It can be noticeable but at least the database application has no problems. I remote into client infrastructure for application design without any problem.

Remote Desktop is a kind of VPN so to speak - but in any case the connection can be via VPN - but again the front end file is co-located with the back end file and does not reside on the local user's PC. If the WAN is skinny and causes lag - that is going to occur no matter what deployment is used and can cause problems. But in the terminal services style deployment that problem does not cause the application to stop working.

[Wyoming]

Thanks for your reply CData,

If I wasn't, now I am completely convinced this is the best approach. Now the fight with the IT crew starts...

[Wendell]

Thanks for your reply CData,

If I wasn't, now I am completely convinced this is the best approach. Now the fight with the IT crew starts...

To confirm what CData said, and add ammunition to your argument, I supported clients all across the country that way for more than 10 years. It works and is reasonably robust. And VPNs turned out to be a pain in most cases. If you are using the latest version of Remote Desktop, the RDP protocol used has been make quite robust and the security issues with the older versions have been resolved. Windows Server 2012 and 2008R2 both support the latest version.