ODBC/OLEDB support for HTTP-based comms to SQL server?

Does there exist an ODBC or OLEDB/ADODB driver for talking to SQL
server over HTTP/port 80?
In other words, I want to be able to issue SQL commands (INSERTs,
UPDATEs, SELECTs) from a client application to a database that happens
to be sitting on a server somewhere that I can only reach via HTTP
(https actually), due to firewall restrictions. I don't want to have
to modify my application, but note that it has the ability to use any
ODBC, ADO/OLEDB or a direct SQL native driver, depending on the
connection string supplied. I certainly don't want to have to care that
requests and results are being transmitted in XML SOAP format (or
whatever).
>From the various connection strings I've seen around, and the little
information I've seen regarding HTTP requests to SQL server, it
certainly isn't possible with the standard drivers etc. that Microsoft
supply, but if so, surely there's a demand for such a thing?In article <1163482089.627876.121280@.h54g2000cwb.googlegroups.com>, wizofaus@.hotmail.com wro
te:
>Does there exist an ODBC or OLEDB/ADODB driver for talking to SQL
>server over HTTP/port 80?
>In other words, I want to be able to issue SQL commands (INSERTs,
>UPDATEs, SELECTs) from a client application to a database that happens
>to be sitting on a server somewhere that I can only reach via HTTP
>(https actually), due to firewall restrictions. I don't want to have
>to modify my application, but note that it has the ability to use any
>ODBC, ADO/OLEDB or a direct SQL native driver, depending on the
>connection string supplied. I certainly don't want to have to care that
>requests and results are being transmitted in XML SOAP format (or
>whatever).
>information I've seen regarding HTTP requests to SQL server, it
>certainly isn't possible with the standard drivers etc. that Microsoft
>supply, but if so, surely there's a demand for such a thing?
>
You're not limited to http, you're limited to port 80
Just set SQL Server to listen on port 80, instead of the traditional 1433.
It sounds like this is at least partly internet accesible.
Be REAL careful about exposed SQL Servers on the net. There are a lot of
exploits...|||Brian Bunin wrote:
> In article <1163482089.627876.121280@.h54g2000cwb.googlegroups.com>, wizofa
us@.hotmail.com wrote:
> You're not limited to http, you're limited to port 80
> Just set SQL Server to listen on port 80, instead of the traditional 1433.
> It sounds like this is at least partly internet accesible.
No, because the firewall explicitly examines the packets to ensure they
are HTTP(S) packets only.
And actually I'd expect to use port 443.

> Be REAL careful about exposed SQL Servers on the net. There are a lot of
> exploits...
Well of course, but as it is the machine has open Terminal Service
access (of course you need a username and password ), so it's not
really less secure exposing another port for direct SQL server access.
The database doesn't hold particularly critical or sensitive data
anyway.
But SQL server *does* have (or at least, can support, along with IIS) a
web based interface...so why shouldn't I be able to talk to it without
caring that it is web-based or otherwise?|||wizofaus@.hotmail.com wrote:
> Does there exist an ODBC or OLEDB/ADODB driver for talking to SQL
> server over HTTP/port 80?
> In other words, I want to be able to issue SQL commands (INSERTs,
> UPDATEs, SELECTs) from a client application to a database that happens
> to be sitting on a server somewhere that I can only reach via HTTP
> (https actually), due to firewall restrictions. I don't want to have
> to modify my application, but note that it has the ability to use any
> ODBC, ADO/OLEDB or a direct SQL native driver, depending on the
> connection string supplied. I certainly don't want to have to care that
> requests and results are being transmitted in XML SOAP format (or
> whatever).
> information I've seen regarding HTTP requests to SQL server, it
> certainly isn't possible with the standard drivers etc. that Microsoft
> supply, but if so, surely there's a demand for such a thing?
>
Have you considered creating some web methods?
That would allow you to consume and utilize SQL data over port 80, but
not open up your entire range of functions.
The Texeme Construct
http://you-read-it-here-first.com