Feb 10 2021 03:11 AM
Feb 10 2021 04:24 AM
Feb 10 2021 07:03 AM
In addition to Daniel's suggestions, you could consider a hybrid approach. Keep your existing Access Front End, or interface, on your desktops internally, but move the tables for your relational database application to a hosted SQL Server, or to SQL Azure. Then you will need to create the browser-based interface to those same tables for those who need to use it from mobile devices or remotely via a browser.
It all depends on the specific requirements for your organization. There are multiple options, each of which has its own advantages and disadvantages. Unfortunately, browser based Access web apps is no longer one of those options.
Feb 10 2021 09:03 AM - edited Feb 10 2021 09:09 AM
Thank you so much. Can you suggest me some program that can replace MS Access and satisfy my requests?
Feb 10 2021 12:54 PM - edited Feb 10 2021 12:55 PM
If your needs are relatively simple, perhaps you could turn towards Microsoft powerapps.
Otherwise I'd recommend a proper web language such as PHP, .net
Feb 10 2021 08:10 PM
Keep in mind that a relational database application is composed of three main tiers, or layers.
Access is quite unique in that it includes all of those objects and tools. Most other development environments include only the 2nd and 3rd, leaving you to choose a database engine appropriate to your needs.
However, Access does not limit you to its own proprietary database engine (which is called ACE by the way). Access can connect, or link, to a huge range of other data sources, including those listed above as well as SharePoint lists, text files and Excel files. This means that any data storage you choose can be the data layer for a proper web app, and that Access can ALSO link to it to provide an in-house desktop interface.
The next thing to consider is that whatever interface tools you select will come with their own learning curve, greater or lesser depending on what you choose. Things like .net or php which are needed for a browser based interface may be more or less challenging to you, in other words. Again, depending in part on your skills and aptitudes, you might be up and running fairly quickly, or not. One thing you should NOT consider, though, would be to use Access tables as the data layer for other interfaces.
And finally, I would like to offer the observation that Access is a tool used to create one specific class of relational database applications. I would probably approach the task as looking for other tools to SUPPLEMENT, not to replace Access in your tool kit.