Re: Here's a rather broad question...

Frankly I have no preference as to what underlying technology is being
used
to access the database; my requirements are simply that I use ADO in my
ASP
code and SQL Server 2005 (x64) as my backend.

Right. On that basis, I would be looking for using Native OLEDB providers
("providers" is Microsoft parlance for an OLEDB "driver") as that is what
ADO likes best and is simplest. I take it as axiomatic that adding in
additional intermediate layers complicates things and that simplest is best.

Note, I assume you know that ADO is just a lightweight COM layer to avoid
the complications of programming in OLEDB. There is little overhead in using
it.

The data route should be

ASP code & pages <--> ADO <---> OLEDB SQLServer Native Provider <---> SQL
Server 2005

Had you been using ODBC it is more complicated

ASP code & pages <--> ADO <---> OLEDB ODBC Provider <---> ODBC driver <--->
SQL Server 2005

I'd prefer to have a user
with *very* limited access to the machine and the database (that user only
needs to perform a few SELECT statements), but throwing tight security in
at
this point IMO is just adding an extra layer of complexity...

Right. My thoughts exactly. Get the basics working.
Beef up the security once you have a working prototype.

Cheers

Stephen Howe


.