http://qs321.pair.com?node_id=542611


in reply to Re^3: Dynamic Web Page approach?
in thread Dynamic Web Page approach?

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.

Replies are listed 'Best First'.
Re^5: Dynamic Web Page approach?
by Anonymous Monk on Apr 11, 2006 at 18:48 UTC

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

[reply]
      I think you missed my point which is: do you want workstation software running on a server? I then gave an example of where parts of Microsoft Office (a workstation product of which Access and Outlook are both parts of) cannot co-exist with a Microsoft server product. Forgive me for trying to point out potential risks you may not have been aware of.

      I understand how Access works which is why I recommend against it. We used to have an Access frontend to Oracle here. We ran into a serious performance issue where ODBC would not take advantage of indexes. And every time updates to Access were rolled out it could break the front-end (and usually did). And upgrading to a new version of Office always broke the Access frontend. I'm sorry, but if you think Access is a good idea you just do not have enough experience.

      Regarding IIS, ActivePerl ships with Perl for ISAPI so you may still be able to use Perl.

[reply]

In Section Seekers of Perl Wisdom