Re: Using Access for web application?

Thx for the comments. Any suggestions as to which newsgroup would be more
appropriate?

I am quite knowledgeable working with Access offline or local network, but
when it comes to the web, I admit, I'm quite a dummy.

The server that the web app will use in this case, I believe is not
significant since the app will be hosted by an ISP (not by an inhouse
server). So it is not an issue of purchasing server software to make it work.
The ISP can support an Access database.

In this project, it has been tossed around that Dream Weaver would be the
good choice for page creation. I also believe that the pages would be ASP.

I appreciate your confirmation that using Access as a backend database is
not the real issue. That was my feeling also.

One reason I was tending to using Access for the Web app, was that there is
a current offline Access app that is related to this project. My leaning is
that the two projects might interface easier if the underlying software is
also related.

As for religion, well, generally I am a Microsoft supporter whenever possible.


"Sylvain Lafontaine" wrote:

> This newsgroup is about DAP (Data Access Pages) and SQL-Server and, to a
> little extent, about Access' MDB files but only for LAN cases because DAP
> cannot be used with MDB over the Internet (WAN). So, I really don't see why
> you think that this newsgroup could be appropriate; especially when you have
> said that you were not interested with DAP (which is, btw, a good decision).
>
> Your first question should not be about using Access or MySQL but about
> which technology you will decide to use as the Web server (Linux or Windows)
> and on the web server for generating the pages (PHP, PERL, ASP, ASP.NET, ...
> ?). In your contrast, the choice of the backend database is of relatively
> minor importance here.
>
> If you want to have arguments of some relevance to your project, then you
> should provide more details about this particular web project. Otherwise,
> this kind of post will become a religious discussion. (In fact, even with
> more details, this will probably become a heated religious discussion.)
>
> S. L.
>
> "JED" <JED@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:D9D44FB0-7520-443A-99A9-5106DBE7F4BB@xxxxxxxxxxxxxxxx
> >I have an opportunity to work on a web based project using Access. However,
> > there has been some opposition to using Access. Instead MySQL is being
> > suggested as an alternative. The project is actually a small project (less
> > than 4000 table rows) and I feel Access would work well. I won't be using
> > Data Access Pages but would use another product to generate web pages.
> > Because I am not familiar with MySQL, can anyone assist me and offer some
> > comments as a rebuttal to the opposing remarks mentioned below (any
> > comments
> > I make are preceded by "-->")?
> >
> > 1) Access is a horrible system for web applications and building something
> > now in Access would hinder future growth and maintenance. This is for a
> > bunch
> > of reasons...just a couple:
> >
> > 2) Access is not designed to be a web-enabled database - it is designed
> > for
> > desktop use. This means that there are no easy systems for working with
> > large
> > amounts of data, and integration with other systems. --> 4000 table
> > entries
> > is not a lot of data
> >
> > 3) The vast majority of the web runs on Window severs. This is due to the
> > expense of running Windows in a server context (licensing, sysadmin
> > salaries,
> > increased main. b/c of security, etc.) Building something in Access now
> > will
> > mean having to use Windows-based servers, which tend to be more expensive.
> >
> > 4) Doing the system in MySQL makes more sense because
> > a) it is free
> > b) natural for web applications and has lots of built-in functionality to
> > support this context
> > c) there are lots of developers who work with MySQL making the vendor
> > search process much easier
> > d) MySQL is based on a standard language (Structured Query Language)
> > which
> > transition easily to other SQL-style platforms.
> >
> > 5) Go with MySQL unless there is a serous reason prohibiting this.
> >
>
>
>
.