Convert Access FE to web app (1 Viewer)

[tmyers]

Does anyone here happen to have some experience in this matter? I really want a project to learn more new skills and think converting one of my more simple Access apps to a web application hosted on our local intranet would be a good and fun challenge. Any reading material would also be greatly appreciated

 

[theDBguy]

You would have to "pick" a (web) platform to convert the Access app. I think most people choose to use PHP for the code. Just a thought...

 

[plog]

..a web application hosted on our local intranet...

If that's the case, you probably don't have a choice in technology. Ask whomever is in charge of your intranet what database (MySQL/SQL Server/Oracle/Postgres) you can use (and for access) and what scripting language (PHP/ASP.net) to use and an environment to work in.

Once you know the technoogy, get agoogling.

 

[Pat Hartman]

The nice thing about having a working Access application is that you have a database that can easily be converted to whatever the website needs. It should NOT stay as jet/ACE. Although you can create web apps with Jet/ACE BE's they can't handle anything except very low traffic volumes. Then you need to rewrite the FE in a different platform but at least you have a working template.

Web apps are not inherently "better" than Access apps. The Web app has the advantage of being available via the internet so people can work from home. This became very important in the era of COVID. But the Access app is more user friendly and can automate other Office products to increase its range of features.

So, make sure you pick an application that does not need to integrate with Office.

 

[GPGeorge]

Does anyone here happen to have some experience in this matter? I really want a project to learn more new skills and think converting one of my more simple Access apps to a web application hosted on our local intranet would be a good and fun challenge. Any reading material would also be greatly appreciated

One doesn't "convert" an Access form to run in a browser. Microsoft tried to do that at least three times, unsuccessfully.

What you can do is migrate the data from your Access tables to a database that supports the brower/web environment, as Plog noted.

Then you can acquire and learn some sort of web development language to create web pages that will run in the browser.

PHP is an option, but so are various other .net framework development languages, C#, VB.Net, JavaScript and a startling array of flavors among them.

Still another option, which you might consider depending on your organization's environment, could be PowerApps. See this series of videos on one example of a Hybrid application which has a SQL Azure backend, an Access interface and a PowerApps interface.

As Pat noted, and I should have included, the "heavy lifting" is, and always will be, done in the Access interface.

 

[tmyers]

I was thinking of trying to use...I think it was called Flask? For the webform development. A friend told me it was somewhat easily to learn, if I am remembering the correct one anyways. I have heard PHP mentioned a lot for this as well, but no nothing about it so will definitely be reading up on it.

My backend for the Access app I am attempting to "convert" already uses SQL Server, so I at least have that covered thankfully.

One doesn't "convert" an Access form to run in a browser. Microsoft tried to do that at least three times, unsuccessfully.

What you can do is migrate the data from your Access tables to a database that supports the brower/web environment, as Plog noted.

Then you can acquire and learn some sort of web development language to create web pages that will run in the browser.

PHP is an option, but so are various other .net framework development languages, C#, VB.Net, JavaScript and a startling array of flavors among them.

Still another option, which you might consider depending on your organization's environment, could be PowerApps. See this series of videos on one example of a Hybrid application which has a SQL Azure backend, an Access interface and a PowerApps interface.

As Pat noted, and I should have included, the "heavy lifting" is, and always will be, done in the Access interface.

I did manage to get my IT to unlock Power Apps for me awhile back, but have not yet had the pleasure to play with it. Think that would be easiest then trying to learn my way through PHP, ASP.net etc?

 

[plog]

Powerapps would be the easiest to learn.

 

[GPGeorge]

Powerapps would be the easiest to learn.

Maybe so. At least it's in the same eco-system.

 

[GPGeorge]

Powerapps would be the easiest to learn.

You will, no doubt, find the licensing costs "opaque".

 

[Pat Hartman]

I don't believe that Power Apps can create an "equivalent" application. but I'd be happy to be wrong because it would provide an alternative even if we have to recreate the app manually.

 

[561414]

I have experience with React/Antd for the UI and Node/MySQL/Express for the backend, you write your code in JavaScript. You can setup a server within your intranet in a matter of minutes with these. As for the UI, the Antd library of components is excellent to modernize your Access App.

If you like Python, then don't bother with these and go with Flask.

 

[GPGeorge]

I don't believe that Power Apps can create an "equivalent" application. but I'd be happy to be wrong because it would provide an alternative even if we have to recreate the app manually.

When I refer to hybrid, I mean that pieces of the app that can benefit from being available in the browser could be replicated.

The "heavy lifting" is, and always will be, done in the Access interface.

That said, I've had some interesting experiences so far. I'd love to have a chance to see how far it could go. Right now I'm wrapping up a three-part video series using AI in a PowerApps app. When that's done, I should have time on my hands for a project like that.

 

[tmyers]

I have experience with React/Antd for the UI and Node/MySQL/Express for the backend, you write your code in JavaScript. You can setup a server within your intranet in a matter of minutes with these. As for the UI, the Antd library of components is excellent to modernize your Access App.

If you like Python, then don't bother with these and go with Flask.

I have been learning Python over the last few months off and on. Its syntax doesn't differ that much from VBA, so it hasn't been too rough learning it. I was reading more on Flask last night and will likely try to use it first.

 

[561414]

I've always considered the best way to get into web development is by creating an app that you're genuinely interested in using. Not only will this keep you motivated, but it will also help you understand the effort required to bring it to life. Project-based learning will give you hands-on experience and a deeper understanding of the development process than any tutorial or guide you mindlessly follow. You'll have to go through all the necessary steps, from designing to coding to deployment, and this will help you develop crucial skills along the way. You'll be tempted to rewrite it as soon as you finish and that's good.

So start by building an app that speaks to your interests and needs. It may be a challenge, but the experience and knowledge you'll gain will be well worth it in the end. Or tell about this to a client that trusts you, get paid while learning how to turn their Access app into a web app.

One big advantage of Flask and Python over JavaScript is the amazing quality of its libraries for data analysis and calculation and its vast amount of support. You will get the best of it if your app handles big amounts of data.

 

[Pat Hartman]

Or tell about this to a client that trusts you, get paid while learning how to turn their Access app into a web app.

Always make sure that the tool can actually reproduce what the Access app does. If you need to import/export files or automate Word or Excel, make sure the web tool can do that. I think that most can send eMail but automation is com to com so that will be a challenge.

 

[561414]

That's only if they want to output a Word or Excel format. If what they want to do is generate printable documents, HTML is way more stable and customizable than Word, and PDF files can be generated from it. Same for Excel tables and documents. But if you wanted the .docx or .xlsx file, then there are plenty of multi purpose libraries that can generate that from scratch, some of them even support templates that can be filled by sending data from the app's resources. Some libraries allow you to be very precise in your documents. It's a pretty rich environment, full of open source and paid-for solutions, depending on the client needs. And that's without even touching the Office JavaScript API, which I have used to develop Excel Add-Ins. And even if all of that fails, the web app can simply trigger the opening of a file stored in the server, and this file can be programmed with its native VBA capabilities, produce an output and the web app simply observes until the file is done.

Plenty of options, some easier than others, but we are at a point where we do not need to reinvent the wheel.

 

[Pat Hartman]

That's only if they want to output a Word or Excel format.

That's the point. I'm not making a judgement. I'm telling you that you need to be sure that whatever tool you are moving to can support the actual requirement. For example, you would never start with Access as a platform if you needed to support anonymous access from the web but if you didn't know that at the beginning, you would be very disappointed later. You can distribute Access over the web using Citrix and RD but you can't take that final step to allow anonymous users.

 

[Lightwave]

Personally - I would convert the backend to SQL Azure or SQL Server and join your MS Access front end to that... (not necessarily a small job)

Next learn web development and work concurrently on the new web front end while at least maintaining the access front end.

This really protects you should you find you are unable to make progress with a web front end. Tools are getting better for web front end but its still quite a bit more complicated than MS Access and there are some things like dynamic save / really nice reports and the excellent code behind system - that aren't necessarily built into web front ends.

Quite often people think they will just mirror the usability built into MS Access as a UI on the web... with the above even if you can't mirror exactly all the usability you can take advantage of each platforms strengths which can be a big step forward in itself and importantly this gives you time to develop some of the more complicated stuff from Access to the Web.

It may also give you time to learn some of the more complicated aspects of SQL, like window functions / the real value of immutable design / stored procedures and CTEs which if you are only using the JET engine you might not be familiar with.

And if you are looking for a code generator PHPRunner (link to XLinesoft Company website below) is working really well for me , I have thoroughly tested PHPRunner and I find it stable and dependable and that it works well with SQL Azure. I have two production databases using it and I host both on Azure and cPanel on LAMP Stacks linked to either MariaDBs or SQL Azure. Interestingly if you build a project you can convert between PHP and ASP.NET (although you have to purchase and additional product) and vice versa although having used both I found PHP to be faster and I have a greater choice in hosting companies by going the LAMP stack route.

PHPRunner - PHPRunner

 

[tmyers]

I have been doing a bunch of research and I am going to give Flask a try for my first attempt. The results should definitely be interesting.

 

[Gasman]

Do report back on your progress. ease of use etc.