+1  A: 

I don't have any experience migrating access to a web-based interface, although I have heard of people going straight from access to a web page. MySql is exceptionally easy to migrate. MySQL.com has a program called mysqldump that comes with the standard install of MySQL that allows you to export your database straight to a text file that can be used then with mysqldump to import it on another server. I don't believe the WAMP server comes with the command line tools although they can be downloaded from mysql.com. However, if it has phpMyAdmin, then there is also an export feature with that as well that will generate a .sql file that can be imported to the webserver using phpMyAdmin. One thing to keep in mind though is that I have had very little success mixing and matching these methods: ie, I've never been able to get a mysqldump-created file to work with phpMyAdmin and vice versa.

Good luck!

Chris Thompson
+1  A: 

The link will help you to export and import mySQL database

May be on Windows web server there is an opportunity to run Access files, you can check, but any way if you have some programming skills, I would say that it is not difficult to crate a php script which will query your database info and will edit.

Narek
How does this answer a question about front end development? He didn't say his data was in Jet/ACE -- it's already in MySQL.
David-W-Fenton
+1  A: 

If your webserver has TCP connectivity to your existing database server, and its hosted in a suitable place (eg, don't have your webserver in a datacenter connecting to a database server on your office DSL connection), then no move is required.

If you do need to move it, it's as easy as creating a backup/dump, and restoring it elsewhere.

As far as the frontend, there are MANY technologies that will do what you need (ASP.NET, PHP, Python, Ruby, Perl, Java being the most popular ones, not necessarily in that order).

  • Use something you are comfortable with, or that you are interested in learning (provided you have the time to do so)
  • Use something that runs properly on your target webserver. Really, ASP.NET is the only one that has any major issue here, as it's limited to Windows.

Access itself has no direct web-accessible version. A Google search finds some apps that claim to convert Access forms to web-based, but I will not link to any because I don't know how well they work. I'm certainly leary of anything like that, because web apps are a different breed from Windows apps. If you are going to go that route, be sure they actually generate HTML output; make sane, clean source; and offer a free trial so you can verify it actually works.

Really though, a form like that is reasonably easy to reproduce with some basic knowledge of server-side programming and some HTML.

gregmac
I've looked at the demo versions of each of these Access forms to web converters as I've become aware of them, and not a single one of them is usable. They either ignore tons of the functionality in the Access form or they try a 1:1 conversion, which is completely inappropriate for stateless apps (which is what web apps are).
David-W-Fenton
A: 

Migrating an Access application to the web is quite difficult, because you can't translate an Access form 1:1 into a web page. Web apps are stateless, whereas Access is built around the concept of bound controls and bound datasets.

Secondly, it is impossible to easily replicate an Access subform.

Third, you lose tons of events that Access forms and controls are built around.

In general, a web page that performs the same task as an Access form will bear little or no resemblance to the Access form, simply because the methods for accomplishing the same tasks and the UI widgets available to you are so completely different.

One thing to consider is whether your users need a web application or if they just need to use your existing Access application over the Internet. If the latter is the case, Windows Terminal Server/Citrix can do the job for a lot less money, since there's no conversion needed. You do need to provision a Windows Terminal Server, set up a VPN and purchase CALs for the users, but the costs of those are going to be much less than the cost of rebuilding the app for web deployment.

It may not be an appropriate solution, but it's one that you should consider, I think.

David-W-Fenton