Discussion on:

10 reasons to turn your Access applications into Web-based applications

Great thing to point out.

One upcoming limitation though, is that JET is for 32 bit only.
This means that on a 64 bit OS both JET and the web server (IIS) must run in the same 32 bit subsystem.

/gustav

You can easy switch access to work with SQL server, it much more easy then converting to web app. for #2 and #3 terminal server solutions works fine

SQL Server isn't cheap, for one. A web server both hardware and software is a fraction of the cost of just the SQL Software.

Plus, there are many advantages (listed in the article) for the advantages of using a web interface from your Front End.

I happen to agree with the authors, but they laid out the case extremely well.

Full Disclosure:

we make a product - Alpha Five v9 Platinum - www.alphasoftware.com - that is designed to let you build custom ajax enabled web apps against any SQL backend (including Access) in much less time than in PHP or RUBY or Java or Dot Net.

You can download on our site and the first 5 people who email me at richard@alphasoftware.com will get a no charge full copy

thanks
richard rabins
www.alphasoftware.com

We are encountering this exact problem at work and would like to port it to the web. Currently, we are wondering which web language to write the front end in? Does anyone have any formal experience or good recommendations. Currently the database only has a few forms but would need the ability to generate reports (which are currently done through macros) to create a word document. Any suggestions would be great!

If you would like a phone/web demo of a fast web 2.0 (ajax enabled) app that can be created in a lot less time (and less hassle) than DOT Net - email me at richard@alphasoftware.com and we can set that up.
Richard Rabins

I work for a government agency, that has about 10,000 employees, most of which have a PC that is hooked up to a large network, that reaches out about 500 miles in distance. It seems to me, that at my agency, there is no way to ensure that a shared MS Access database will not get corrupted, considering that there are too many factors that are out of my control (I have no control over people's PC's, or the network routers, network connections or servers). What we are doing at my agency, is trying to avoid MS Access for medium to large sized shared databases, and instead we are using a web front-end on a ColdFusion server, and putting the back-end data onto a server that uses DB2. At my agency, a few of the MS Access databases have gotten so corrupt, that there is no way to fix them, and yet still, more and more MS Access databases are being put onto the servers and shared (perhaps this is because there are not enough programmers available who know db2 and ColdFusion). At my agency, the "standard" for medium to large databases is DB2, and this is why we are not having the ColdFusion point to an Access database. We have other font-end platforms at my agency (such as Java, .net, and others), but the ColdFusion is very popular at my agency, since it is already in wide use here, and it is easier to learn and use than Java or .net. I would like to add that, at my agency, MS Access is a great application for small stand-alone databases that are kept on the c-drive of a PC, and are backed up properly, and I personally have several Access databases that I use in this way (both at home and at work). However, I think that many people don't understand the limitations of MS Access, and get into trouble when their shared MS Access database gets corrupted. Thanks for your articles "10 reasons to turn your Access applications into Web-based applications" and "10 ways to prevent Access database corruption", as this has been some very interesting, helpful, and informative discussion on these subjects.

see any reason to use Access at all.
MySQL and PostgreSQL are both much easier to use, scale to handle millions of simultaneous transactions, and are free. Why should I spend money getting Access when I have far more capable tools already?

I agree -- use the tools of your choice and the best tool for the job that's available. That's exactly as it should be.

Let me start this off by saying that I agree that I don't think access should be used for business critical applications...

However, as a lot of businesses already have MS Office Pro, they already have a copy of Access, so installing it is not another financial expense (as they already have the licence)... hence, for the less tech savy people within the business that are already very familiar with the look and feel of other Office applications, installing and using Access to perform a task, is far easier to them than to try and download and setup MySQL etc. Plus I'd be willing to wager that most non-it people within any business would more than likely not even have heard of MySQL and PostgreSQL, let alone know how to get it up and running!!

My 2 cents worth...

This is an interesting article, but I am left unsure about how exactly you would do this at a practical level. What tools are there to provide the web server level that would sit on the server? Is it possible to give some specifics for an example system?

Here is a white paper on moving an MS Access Application to the web

Thanks
Richard Rabins
www.alphasoftware.com

http://www.gregoryfca.com/blogs/Alpha/documents/Alpha_MovingAccess_WP_FINAL.pdf

Concordo perfettamente con tutto quello che hai scritto. L'obiettivo finale di Access era proprio questo, venire utilizzato su server web dalla applicazione web. E' piu veloce, pi? semplice e pi? manutenibile ma questo i veri sviluppatori lo sanno...
(non tutti per?...)

from a microsoft technet systemist by Italia

ciao

manarolla.vincenzo@euro1.it

?

Am looing at developing MS Access application but would ideally like it web based.
Is this possible and if so how?

What about front ending MS Access with Visual Basic - how difficult is this?