This is an attempt to use RDS (Remote Data Service) over DCOM. This means you will need to have DCOM connectivity to the remote server, as well as have the ADISAPI component installed at the server. The latter is an IIS extension "stub" to make IIS handle your database requests and open the actual database and fiddle with it.
RDS was previously "sold" as a way to give web-client code access to databases on a remote server - via DCOM or HTTP. As various cracker exploits became clear, it was "sold" only for intranet use - too dangerous to expose to the public internet.
Very rarely did anybody ever use it from ASP, that'd be pretty exotic. RDS has pretty much been replaced by SOAP. It is almost like you are "wishing" Access to be a true client/server database like SQL Server or Oracle or something.
These days RDS is generally not installed or is left crippled to save box-jockeys ("system administrators"
the trouble of policing its secure use. Various "IIS lockdown kits" have been put out, and I believe all of them disable or de-install RDS.
In your case, for low-performace ASP applications people relying on .MDBs usually put the database right into the virtual directory housing the ASP app... or a subdirectory of the vdir. Of course you still need to deal with permissions.
Even FrontPage will create a Jet database like this for you in a web if you use its simple forms-to-database stuff.
For real work you'd need to discard Access and Jet, but it may be fine for what you want to do.
But what is really scary is that it appears that your Access DB is sitting over on yet another file server or something. Performance is gonna bite bigtime if you have to do this. Jet will need to haul and thrash a lotta stuff over the wire to/from that file server. It is NOT made for this.
But to let all that go, and just make your stuff "work" I suspect you can just deep-six that RDS stuff: you don't need all that Remote Provider stuff. Just use the Jet Provider.
I see something like:
Code:
<User>--http--<IIS box X>--dcom--<sr23redpoll>--smb--<sr11hawk>
If "box X" is actually "sr23redpoll" and your ASP pages run in sr23redpoll you clearly have no need for RDS.
Code:
<User>--http--<sr23redpoll>--smb--<sr11hawk>
Your ASP and the Jet engine will run in sr23redpoll, and Jet will have to thrash stuff over the file sharing protocol and the wire (a lot of stuff) to get to the "database" (which Access really ain't - more like an ISAM file) sitting over on sr11hawk. But it'll work, though scalability is poor and depending on your network topology and utilization things could get really yucky.
So if X is sr23redpoll, try sumpin' like:
Code:
conn.open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"DataSource=\\sr11hawk\shared\Vanity_Share\" & _
"WebTemplates\departments\cg\" & _
"community IS\database\Equipment.mdb;"
But keep in mind that the user context your ASP pages run under will need access to this file on the sr11hawk file server.
If X is NOT sr23redpoll (my 1st stick drawing), then sr23redpoll must be an IIS server with the server-side RDS components installed and enabled, and X must be able to "see" sr23redpoll over DCOM (unless you switch to using HTTP). You also need user/pw authentication set up on the server and put into your connection on Open. This is gonna be messy - it is so little used even the docs on MSDN Online have myriad typos nobody cares to correct.
And...
In EITHER case (separate X or X = sr23redpoll) your sr23redpoll needs to be able to see through any intervening firewalls over MS SMB file sharing (or whatever file-sharing you use... Novell? Banyan?
) to that file server sr11hawk.
Good luck. Hopefully others will point out where I went completely off the trolley here.
