Can someone point me which platform I can create forms that link with MYSQL database, the database is already created it works very well when linked to MS Access database via ODBC. Now many people are demanding that the software must be accessible via mobile phones and that is where I need to recreate the forms
Solved How to migrate MS Access forms or recreating forms to the web based forms (3 Viewers)
- Thread starter nectorch
- Start date
Create a web server that can manipulate your Access database, this is the basis. There is a recent thread where someone tried to do it but others are having problems with it. However, there are more options: you can easily create a web server with python, there are python libraries that can read/write to access tables. I would do it via NodeJS and the express library using the ado library from npm.
Once the server is ready, you have two options:
1. Create a responsive web application (responsive means it resizes according to the screen gracefully). This is cross platform because it only needs a browser. Any device with a web browser can use your app.
2. Create an android app and a iOS app.
In any of the two options, you will use the same web server. I recommend the web app, it's less problematic. But native apps have a ton of advantages, like dedicated storage and more solid UX.
Once you have everything ready, deploy the server and the app or apps. There are plenty of options for your deployment.
Once the server is ready, you have two options:
1. Create a responsive web application (responsive means it resizes according to the screen gracefully). This is cross platform because it only needs a browser. Any device with a web browser can use your app.
2. Create an android app and a iOS app.
In any of the two options, you will use the same web server. I recommend the web app, it's less problematic. But native apps have a ton of advantages, like dedicated storage and more solid UX.
Once you have everything ready, deploy the server and the app or apps. There are plenty of options for your deployment.
Last edited:
cheekybuddha
AWF VIP
- Local time
- Today, 16:19
- Joined
- Jul 21, 2014
- Messages
- 3,289
GPGeorge
George Hepworth
- Local time
- Today, 08:19
- Joined
- Nov 25, 2004
- Messages
- 3,433
One option is indeed a browser-based interface, which is quite doable with an AI assistant even if you have little to no experience.
Another is to use Microsoft PowerApps to create the mobile interface. One advantage is that the same app runs on virtually any device, even the Windows desktop.
I assume the reason they want the mobile interface is so that they can use the application while away from their desktop computers. Otherwise, there's no advantage to it. The real estate available on even a large format smart phone is severely limited when compared to even a laptop. I've developed enough PowerApps apps to know how painful it can be to create a usable interface for that format unless you're willing to slim down the features considerably.
And that brings up another aspect of the decision. What, specifically, do people need or want the smart device interface to do? Is it ALL of the functionality of your Access app? Or are there elements of the app that can be usefully supported for mobile use? Data input, for example. How about reports? Do they need to be on a phone? Can your basic reports even be created so that they are usable?
I suspect that sometimes people want their apps on their phone just because they want to have them there, not for any practical reason. If your users do have practical arguments for a mobile interface, fine. That's not hard at all. But do take the time to sort out the whys and the whats of the request.
If you do want to learn more about using PowerApps, check out the videos on my YouTube Playlist. https://youtube.com/playlist?list=PLQgLuLFqAr9-PoMhLpCWZmtzwgEulKvH5&si=Ryo1kwO_Nr67Ddl0
Another is to use Microsoft PowerApps to create the mobile interface. One advantage is that the same app runs on virtually any device, even the Windows desktop.
I assume the reason they want the mobile interface is so that they can use the application while away from their desktop computers. Otherwise, there's no advantage to it. The real estate available on even a large format smart phone is severely limited when compared to even a laptop. I've developed enough PowerApps apps to know how painful it can be to create a usable interface for that format unless you're willing to slim down the features considerably.
And that brings up another aspect of the decision. What, specifically, do people need or want the smart device interface to do? Is it ALL of the functionality of your Access app? Or are there elements of the app that can be usefully supported for mobile use? Data input, for example. How about reports? Do they need to be on a phone? Can your basic reports even be created so that they are usable?
I suspect that sometimes people want their apps on their phone just because they want to have them there, not for any practical reason. If your users do have practical arguments for a mobile interface, fine. That's not hard at all. But do take the time to sort out the whys and the whats of the request.
If you do want to learn more about using PowerApps, check out the videos on my YouTube Playlist. https://youtube.com/playlist?list=PLQgLuLFqAr9-PoMhLpCWZmtzwgEulKvH5&si=Ryo1kwO_Nr67Ddl0
No, I do need Ms. Access anymore, I have migrated the database to MySQL database Maria I have tested this people are working ok with MS Access as Front End by using ODBC. The only problem is that people want to use smart phones to access the software that is why am looking for alternative
Hi 
Is going to sound like spam or that im a seller or something, i know hahhahah but... if u use AI assistant, u can use my MCP for making an android application from scratch (github.com/unmateria/MCP-B4A), if already have all the functionality in your Access database, use my other mcp at the same time (github.com/unmateria/MCP-Access) and it will recreate the full APP from the Access database forms from scratch. Sounds like magic, but if you use CC with both MCP, i promise u that works.
MCP-B4A makes that your claude code, claudish or whatever u use can develop applications in B4A (Basic for Android). I bet you can use it in B4X too, but I didnt tested it.
MCP-Access just makes the LLM can use, edit or understand your Access like if it was just native trained on it.
Altough nowadays and without looking your current app, I would explore the posibility of a fastapi api server + WASM. Any LLM can do it for u EASY (they have already good training on that)
Is going to sound like spam or that im a seller or something, i know hahhahah but... if u use AI assistant, u can use my MCP for making an android application from scratch (github.com/unmateria/MCP-B4A), if already have all the functionality in your Access database, use my other mcp at the same time (github.com/unmateria/MCP-Access) and it will recreate the full APP from the Access database forms from scratch. Sounds like magic, but if you use CC with both MCP, i promise u that works. MCP-B4A makes that your claude code, claudish or whatever u use can develop applications in B4A (Basic for Android). I bet you can use it in B4X too, but I didnt tested it.
MCP-Access just makes the LLM can use, edit or understand your Access like if it was just native trained on it.
Altough nowadays and without looking your current app, I would explore the posibility of a fastapi api server + WASM. Any LLM can do it for u EASY (they have already good training on that)
GPGeorge
George Hepworth
- Local time
- Today, 08:19
- Joined
- Nov 25, 2004
- Messages
- 3,433
Can you elaborate on the costs and resources required for a small to medium sized organization if they elect to create, say an Android app, or an iOS app, for their own internal users. How do they deploy and manage the app? How do they determine which users are "licensed" by that organization to use an app?
What additional costs are required, if any, for the infrastructure required to deploy and manage phone apps?
Developing the actual interface app is one part of the total picture and I can easily see how AI assistance can make that less of a hurdle. What I am more interested in is the supporting architecture required to make it work.
What additional costs are required, if any, for the infrastructure required to deploy and manage phone apps?
Developing the actual interface app is one part of the total picture and I can easily see how AI assistance can make that less of a hurdle. What I am more interested in is the supporting architecture required to make it work.
I dont know if I understand ok!
For the fastapi server? just use a cheap vps server or a CNAME on your domain to a VM in your home/office. For just deploying APK I would suggest just sign the apk with b4a and manually install from a fastapi route (is all free) and if you need more security, just add a wireguard layer for VPN. Anyway... what do you call a medium organization? Because for a fastapi server + mysql + VPN maybe is not the best architecture (surely is not)... I dont know what kind of app and data we are talking about! 
I dont know if we are talking about a 'neighbour community' app, a multiplayer game, or an erp based app for 100 employees!! Anyway, nowadays all the backend can be made by the LLM too... I use CC to implement complex integrations in multiple servers at the same time via SSH/WinRM and works like a charm (just ALWAYS make a plan, and ALWAYS review and check the results... fails little, but fails).
- Local time
- Today, 10:19
- Joined
- Feb 28, 2001
- Messages
- 30,932
When I was working with the U.S. Navy, we had a circumstance where we needed to convert some forms because we were changing from one particular DB to another, and both products had their own proprietary form structure. We found the specifications for building form descriptors for the target system and wrote some code to place form controls by iterating through the forms, for each form iterating through the controls, and essentially translating one set of forms to another "form language." That made the static part of the form. We were also able to build the simpler linkage specifications, too, though sometimes we had to do a little touch-up if there was any type of animation or dynamic nature to the forms - like control buttons appearing or disappearing based on data conditions. Considering that we had over 240 tables and a LOT MORE than 240 forms, the automated conversion was quite a timesaver. I also had to do a conversion of a data "backup dump" of the tables to an importable version of the live data. Turned out that we were able to do the complete migration over one long weekend. Down Friday night, up Monday by mid-morning. With SEVERAL runs to the local coffee shop.
I can describe it but can't publish it because it was code done "for hire" which made it the property of the U.S. Navy, and they have not relinquished any rights on that code. Nor could I take it with me.
In any case, if Access is the source, then the trick is merely to learn how to build the forms for the destination utility and how to manage the linkages to data, because Access has everything you would need available as a format or data property.
Unless, of course, I totally misunderstood the goal here.
I can describe it but can't publish it because it was code done "for hire" which made it the property of the U.S. Navy, and they have not relinquished any rights on that code. Nor could I take it with me.
In any case, if Access is the source, then the trick is merely to learn how to build the forms for the destination utility and how to manage the linkages to data, because Access has everything you would need available as a format or data property.
Unless, of course, I totally misunderstood the goal here.
