I was in a similar situation once. I used flat files for news, comments, menus and all the data that was needed for the website. If you choose consistent file names, you can munge the names/directory/file contents with Perl easily.

I'm pretty sure thats what I am going to have to use. Thanks for your reply

Chris DeGrace

Beware that Access will silently truncate really big tables when outputting to CSV: 32k or 64k row limits on depending on your version of Access.

It's sounding more and more like a CSV Document is the way to go for this project.
Basically, the end result is going to be a CGI script I could either send a model number to, or maybe a manufacterer and have it return all the equipment that matched it, I'm sure you get where I'm going with this.
But is a CSV document with roughly 5,000 pieces of equipment, each with possibly 5 fields attached, going to cause a major Server bottle neck? And if it does, might there be a better way to get around it.

Chris DeGrace

I read your post twice, and still have no idea what you're looking for from us. You have an Access database, but no access to your web server. Are you asking how to connect to a remote database from your web server? And, if so, have you considered any particular Perl-based strategies thus far?

Those who know that they are profound strive for clarity. Those who
would like to seem profound to the crowd strive for obscurity.
            --Friedrich Nietzsche

Sorry about being so vague, I always fight with whether to include more details, or include less so more people will actually spend the time to read it. I don't like wasting people's time, expecially when their trying to help me.
Anyhow, I furthur explained the situation in another reply, here. If you want to take a look, I'd greatly appreciate it.

Chris DeGrace

This is a bit vague, but if I read between all the lines correctly, the bottom line is you have data in an Access database that you need on the web, but the web server can't see the database. Is that correct?

If the data needs to be real-time, what sort of capabilities to you have on each box (web server, database)?

Basically, the database would be managed in Access, doesn't mean it couldn't be output as a CSV though. Basically the only time the information would change is if we aquired new equipment, or if a manufacter's website changed. Just the simple stuff. There would be nothing written to the database from a web service, it would only be read by the web site, and hopefully used to whip up HTML pages based on the information it contains.
I hope that was more helpful.

Thanks,
Chris DeGrace

You might consider statically publishing your pages then if that's possible; i.e., don't worry about hooking the web server up to the data directly -- just generate the pages you need from the database every time data is added, then copy (publish) those to the live site by copying the static HTML pages over. There are more sites than you might think that work this way. It depends on how much you need to do against the data; e.g., if you need advanced searching this may not work. Then again, it may if you run a page indexer (many free ones available) against the published pages. This option often looks cumbersome and clunky until you start scoping out the alternatives.

I'd at least line up the pros and cons of the static publish approach if that's at all an option. If not, you have several other options I'm aware of:

• Export the Access data to something you can use as a database on your web server box. If this is simply an issue of a UNIX server not having the ability to host Access, then my first choice would be to import to a native relational DB on the UNIX side. e.g., export from Access to some intermediate format (e.g., CSV) then import that to a true relational database on the other side (e.g., MySQL, Oracle, etc.)
• If you have no DB capabilities on the web server side then you'd be limited to access through CSV or other flat file formats. DBD::AnyData may be useful here.
• Non-MS systems can access a MS hosted Access database via ODBC. There are, for example, ODBC drivers available for many UNIX systems. If you install one of those, you can then use DBD::ODBC to access the data.
• You may be able to use DBD::Proxy to proxy a web server database request over to the MS box running Access. This would also require set-up of a DBI::ProxyServer on the MS box.

Thanks for the tips steves. I'm looking into a few of your suggestions now.

Chrtis DeGrace