Forum Discussion
Solved
Migrating Access back end to the cloud
Hi. I am an amateur. Using Access 365, I have created a small Access database for a local charity and I would like it be usable by 3 or 4 people at once and so I think I need to get the back end (t...
- Do you want to run this relational database application as a web - browser based application, or as a desktop application?
I don't know which "guys in India" you mean, or what they recommend, but you really don't need a lot of other software packages if you are going to continue to use this as a desktop application. However, if you want to replace the Access interface with one that will operate in a web browser, you WILL have to invest in and learn to use the appropriate tools for that.
So, start by explaining who will actually use it, where they are physically located (in a single facility or dispersed among several) and how you anticipate using this relational database application. From there, we can examine some options.
Hi Graham,
if I understand correctly, you want to connect a local Access frontend to a database (Access, MySQL or SQL Server) located in the cloud.
On the Access frontend it should be possible to view, modify and delete data as if the database was local.
From my point of view, a database connection from the cloud to a local frontend (of any kind) is not practicable today. Because much too lame.
For this purpose it is much better to use a terminal server system, which can be operated either locally at the customer's site or alternatively as a VPS (virtual personal server) from the Cloud.
In the form of a remote app, the Access frontend solution can then be operated on the terminal as if the program (Access frontend) were installed locally there.
Many greetings
Stephan
Lots of companies would disagree with that conclusion. If it's done right, Access/SQL Azure is just fine.
Other options, such as a VPS are also just fine.
At some point, cost has to be considered as well. It's all well and good to recommend an approach, but if the implementation cost is high enough, it's totally impractical for many situations. One has to consider the entire picture.
One reason we see people trying to get by with SharePoint lists, or OneDrive or DropBox, is that the costs of other implementations are outside their budget.
Other options, such as a VPS are also just fine.
At some point, cost has to be considered as well. It's all well and good to recommend an approach, but if the implementation cost is high enough, it's totally impractical for many situations. One has to consider the entire picture.
One reason we see people trying to get by with SharePoint lists, or OneDrive or DropBox, is that the costs of other implementations are outside their budget.
- The only "impractical" situation for VPS use of an Access solution, in my estimation, is for personal use. That is, whenever you can't afford your own terminal server (or alternatively a hosted VPS).
A company that cannot afford this is, in my opinion, doomed to failure.
The alternative cost of using the Access solution via terminal server/cloud VPS would be to redevelop a PHP front end as a replacement. We all know what that costs.- "A company that cannot afford this is, in my opinion, doomed to failure."
I wonder how many thousands of small businesses would agree they are doomed to failure on that basis. Or maybe the count is in the millions....- The cheapest VPS with 4 cores, 8 GB RAM, 200 GB SSD storage and AMD EPYC™ cost just 180 EUR net per year.
And what exactly is the viable alternative to bringing Access to virtually any mobile device?
George_Hepworth I completely agree. There are various solutions for putting the back end in the cloud but it terms of cost and complexity using DropBox for a small company without an IT department is a viable option. Just wish there was a simple good one.
- Well, I don't think DropBox is a good alternative for Access applications, though. Therein is the problem. As noted before, in order to share an Access accdb, the file system MUST support the ability to update only one part of a file, e.g., CRUD operations on records in a table. At the same time, other users can also be updating other parts of the same file, e.g. CRUD operations on other records in the table or other tables. The lccdb locking file you see when an accdb is in use is part of that; it tracks who is currently operating on that accdb.
The key is that changes are saved without replacing the entire accdb. And, as a result, multiple users can share the Back End.
Windows supports that.
DropBox and OneDrive, and similar services do not. It's "all or nothing" when saving changes in those environments. If two people have tried to change different records in the same table, or in different tables, the last to save wins all the chips. I.e. their copy of the accdb -- with their changes in it -- overwrites the original accdb, including any recent changes made by other users.
Obviously, in a single user situation, that works, because that one user is not contending with other users to keep their own changes. In a multi-user situation, it becomes a management circus, at best.
SharePoint lists, on the other hand, CAN be used in a manner similar to the way an accdb on Windows handles changes. It's not free because you must have at least one MS 365 account to host the SharePoint lists, but it is, at least, a mult-user capable approach.Using DropBox also does not bring the frontend to any operating system, but only to Windows systems (as opposed to Terminal Server/VPS).
An Access application deployed via a remote app on an Android or Apple smartphone or tablet will run there with a few adjustments just as it would on a normal Windows desktop (apart from the limitations imposed by the small screen).
