Upgrading from Access to a desktop browser application

Question

I have inherited a legacy Access app. I want to modernize the app and turn it into a standalone, browser based desktop application that hits the local Access database in the background. No Web work at all for this one. I know my way around Access very well and I know enough Java, etc. to be dangerous.  

I would love a gui driven tool that will enable me to design windows, read/write to the database, write code in the background, etc., kinda like we do in Access, except it produces html/javascript code for browsers. 

Any suggestions? Has anyone done something like this before, and if so, what tools did you use? Thanks in advance!

Answer 1

We are doing the research about your problem. There might be some delay about the response. Appreciate your patience.

Answer 2

I suspect David_JunFeng's response to you might have been a little tongue-in-cheek... (though I'd love it if Microsoft introduced something exciting in this direction soon) :-) 

If you do not need Web access and want to build a local application for Windows desktops only, then what you are trying to achieve will be much harder to build outside of Access, honestly.

If you literally want to run an "app" in a browser (without using Access Web Apps), you would probably have to host a LAN copy of IIS, then build an ASP.NET Web application that uses a JET database connection to the Access database on the server.  You'd build your user experience in Visual Studio.

If instead you want to build an actual Windows application using HTML5 + JavaScript, you could consider creating a Universal Windows Application (for Windows 10) that is wired up to a JET data store. I am not familiar enough with the database connections available to WinRT applications to know how easy this would be to do. And of course, your application would require Windows 10 to run.

Alternatively, if you just want to "modernize" the end user experience in Access, there is no need to stick to old-style "switchboard" UI in Access. You can create a rather modern, browser-like experience using a top-level Navigation Form and hosting subforms in Navigation Controls, and instead of using plain datasheets, you can create continuous forms with more control over design. The interface can be as "clean" and uncluttered as you have time to design it to be. All of the applications I have built in Access in recent years have been designed this way to one degree or another.

Answer 3

I'd have to agree with Gary and his last paragraph.  I see no reason why you would want to go to the trouble of building a web interface if you don't intend to publish it on the internet.  Use the tools that are already available to you in Access and re-build a robust new application.

Answer 4

...snip...Alternatively, if you just want to "modernize" the end user experience in Access, there is no need to stick to old-style "switchboard" UI in Access. You can create a rather modern, browser-like experience using a top-level Navigation Form and hosting subforms in Navigation Controls, and instead of using plain datasheets, you can create continuous forms with more control over design. The interface can be as "clean" and uncluttered as you have time to design it to be. All of the applications I have built in Access in recent years have been designed this way to one degree or another.

The game plan is to eventually switch this to an SQL database and make it accessible to people who use Macs instead of PCs.  That's why I'm looking at a browser based application rather than developing something new in Access or using Visual Studio.

Answer 5

I've used Access as a back-end for a small Web application before, and it's not that difficult.  Though you said you wanted to avoid Visual Studio, it has some decent GUI-based tools for building Web applications in .NET.  I believe the Community (free) edition gives you many of the same tools as the Professional version.

If you already know some Java, C# is somewhat similar; and I think you'll actually find the syntax a little "lighter" than Java.