Does anyone know how I can take a current MS Access Database I have and incorporate it (make it) in to a fully searchable webpage? For instance, I have a list of my MP3's on the EMPEG and want people on a website to search it by artist or track.

You don't need an access database for that. Hijack does that already.

But to answer your question, you can do it with web server development tools web server software, such as using ODBC with Microsoft IIS. It requires support on the server side, in other words, you need to be able to install software on the server to do the database interface and lookups. Most people with just a plain-old "home page" at their ISP don't have access to this kind of thing.

Like Tony said, it's pretty easy. You can do it with ASP pretty easily (which is supported by the default IIS installation if you're using Win2K or PWS). You can also do this easily with Cold Fusion, if you can get yourself a copy.

I'm sure there are tons of sites out there that'll have sample ASP code for hooking up to an Access database.

Why couldn't you do it with javascript?

(Non-ASP) Javascript is client-side. He needs to access the database on the server-side.

You could. You need to make a distinction between Javascript running on the client (in the browser), and running on the server (as ASP, e.g.).

The problem is that you need to talk to the .MDB file that Access uses as its database. To do this, you'd need to use one of Microsoft's database APIs. ADO would be the usual choice, since it's easily scriptable from JScript (MS' name for Javascript).

The challenge with this solution is that it takes a bunch of configuration, and that you have the right database drivers installed.

If you want to do it with client-side JScript, you'd need to assume that the client:

a) wanted to download your .MDB file.
b) had Microsoft Office (or something else with the relevant drivers) installed.

It's, on the whole, simpler to do it with server-side JScript. And, believe me, once you've got IIS (or PWS) installed, it's a piece of cake.

There are other options -- IE supports ADO data connections over HTTP (IIRC), allowing you to run the application on the client, while still talking to the data on the server.

The problem with this solution is that it requires a bunch of stuff to be installed on the client -- not least that the client should be running Windows. This is a maintenance/admin nightmare, and should only be considered for intranet applications.

By doing all of the work on the server, you've got a closed system, allowing you more control over what's going on.

One possible problem with this, however, is that you still have to run MS' products on the server. It's a matter of opinion as to whether this is the right thing to do.

Personally, for an intranet site, I'd run a combination of:

Windows NT Server
SQL Server
IIS (using ASP and JScript)

...and have done.

For an Internet site, I'd probably use:

Linux
MySQL
Apache (using PHP)

...but haven't done.

Ah, ok. I'm learning new things every day.