|go ahead... be a heretic|
Re^5: Dynamic Web Page approach?by Anonymous Monk
|on Apr 11, 2006 at 18:48 UTC||Need Help??|
Do you really want Office installed on a server?
What are you talking about? Do you even know what Access is? Access is not a server daemon. Access is a frontend to existing data sources, be they MySQL servers across the world or local MDB files on your harddrive.
Did you know Outlook and Exhcange cannot reside on the same server?
You made my head explode :( What do either Exchange or Outlook have to do with Access at all? Why do you insist that Access must be installed on a server? What does e-mail have to do with Access? What thought process led to this statement?
Could there be other comptibility isues you may run into later on (e.g. what if they want to put SQL Server on there later on)?
Tools -> Database Utilities -> Upsizing Wizard. Designed for _exactly_ this purpose. But again, you can have any data source you want. Access doesn't care.
Do you want to have to upgrade it at Microsft's whim or lose security patches, etc? If you are using Microsoft Update then it will want to update Access as well.
Again, you do not understand how Access works. It is not meant to run 24/7. Each person in your company who needs the Access data has their own copy of the software (or shared through terminal services, etc...whatever). They update as usual per the company software policy.
And what happens when the project outgrows Access?
Access is not necessarily the container of the data. It can be, but only if you want it to. If the project "outgrows Access" (which I assume you mean if the limits of an MDB file are reached?), move the data to a dedicated database and change the client software to use a connector. And you can use any database you want, provided a connector exists.
You are better off picking MySQL or Postgres-SQL from the get go
In case you haven't figured it out, it's worth repeating: Access is a frontend. It doesn't care where the data is located. You can use Access and MySQL in tandem right from the get-go.
In regards to the actual thread, I second the IIS/ASP solution. Though being a perl fan, I would be interested in your results if you do decide to go with the perl solution :)