Make my Access App Available in Multiple Desktops Through Online

[Moore71]

Hi,
I have an access app that I would want to make available for different PCs online because they are in different locations.
What is the right way to make this happen?
Can I use offline sharepoint or VPN.

Please advice me on better way to make it through.
Thanks,
Moore

 

[jleach]

A bit dated at this point (Access 2010 and 2013 web solutions are not defunct/deprecated), but there's other means that are pro/con'd here: https://dymeng.com/web-enabled-access/

(for a better maintained version, see the link in the first paragraph)

Basically you're probably looking at Terminal Services or a remote backend setup.

 

[Moore71]

Ok thanks,
but which company can I host my BE to.
I think I prefer this option.

thanks

 

[Minty]

Hi Jack,
Great article. I assume that to make the Access deployed FE cloud back-end you need to re-engineer the way data is retrieved, so that only the minimum is moved over the LAN.

So I'm guessing no records on a form open, restricted sets of records etc ?

 

[jleach]

Hi Minty - regarding remote backends with an Access frontend, it is a bit of work to get right.

I generally categorize into three levels of "forgiveness" when it comes to performance and how much care needs to be given:

1 - Access (JET/ACE) backend: very forgiving
2 - SQL Server (or other ODBC) on a LAN: much less forgiving but still not terrible
3 - SQL Server (or other ODBC) over a WAN: very unforgiving, but when done right works very well.

We have a "3 second rule" - no form should take more than 3 seconds to open (and most of them are well within 2 seconds). We achieve this via remote backends as well, but it really needs to be worked at.

You might be interested in a rather in-depth article/whitepaper I wrote on the subject. It seems to be pretty well received: https://dymeng.com/azure-series-05-database-performance/ It's written specifically for SQL Azure, but applies to any remote DB over ODBC (or any onsite LAN server as well, really).

As it happens, I'm re-presenting this topic at this year's Access DevCon in Vienna: http://www.donkarl.com/devcon/agenda.htm (the presentation is build around that whitepaper).

Some things we'd expect to have to do (restricting records on form recordsets) are correct. Some not so much (leaving the record connected via usual DAO tables are fine). Mostly it boils down to how we're querying. If the queries are well constructed, the back and forth between the server are actually pretty good: queries that don't take in the proper considerations can take ages to run though. If you get bored, that article covers all of it in detail.

Cheers,

 

[jleach]

Ok thanks,
but which company can I host my BE to.
I think I prefer this option.

thanks

My first choice is usually SQL Azure. It's fast, (fairly) easy to set up (creating the account on Azure is by far the hardest part) and relatively inexpensive.

I actually started a whole series of articles on how to do this. Try here: https://dymeng.com/resources/azure/ (it's a bit dated at this point: their UI has changed alot since, and some of the little quirky caveats are no longer an issue, but generally speaking it all still applies)

hth

 

[Moore71]

Thanks dear,
I will give a try now

 

[jleach]

Citrix/RDP is far easier: you really don't have to do anything to the app other than maybe configure whatever environment settings you need (paths, etc), whereas a remote BE and local FE tends to be a better user experience, IMO.

Citrix can get costly: $45/mo/user vs $30/mo for a SQL Azure database (depending on size anyway) with as many users as you like. However, the cost of reworking an existing application to perform well with a remote BE can get up there as well, so it's a "pay now or pay over time" choice I think.

I tend to find the user experience of a "native" local app much better as well, and you can integrate with other applications/local filesystem and such more easily also. Typically with a distributed app you won't be making too many assumptions about what the client may be running aside from the access runtime, so maybe not much of an issue there for this case.

In any case, converting an existing, maybe-not-superbly-designed application to work with a remote BE can be a pretty serious task (I've ran into more than one that I declined altogether because it would have been more cost effective to rewrite from the ground up).