Having done extracts from Access using perl to load ClearQuest database using the CQ API and WIN32::OLE it didn't seem far fetched to use Access as the database for this. My guess is that we could just as easily use mysql. I'm familiar with Access and it's a quick tool for prototyping the database so that's where I started.

Why perl? I'd like to continue to extend my perl skills (practice makes...er...well anyway...) and I use them whenever I can, I enjoy it. It is unlikely I'll ever be able to become a truly competent perl developer without continuing to exercise it. I'd also rather go with the devil...er..language I know rather than the language I don't know (ie. VB.NET).

I'm still trying to identify what the hosting platform is for this project. I personally have access to a linux box (RH9) at home and more XP boxes than are really necessary. This is a "extra-curricular" project aimed at satisfying a quarterly MBO objective vaguely titled "build the company" or something equally obscure. The company is small and young. A fair questions is do they know what they're doing? Why was this assigned to me? Because I was available and asked for it. If they had to pay a FTE for this it could be many months before they'd get the work done. gj

I'd have to recomend against Access. Do you really want Office installed on a server? Did you know Outlook and Exhcange cannot reside on the same server? 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)? 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. And what happens when the project outgrows Access? You are better off picking MySQL or Postgres-SQL from the get go. My US$0.02 anyway.

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 :)