4 ms·

Microsoft Shifting To ODBC for SQL Server

52 points by xradionut 15y ago

gaius 15y ago
But what about TDS?
- ximeng 15y ago
  TDS is at the level below ODBC, shouldn't be affected I imagine.
- aninteger 15y ago
  Judging by stack traces ado.net is talking tds directly. Mono's implementation is based off freetds. Ruby has tinytds and of course existing c and c++ programmers can use the freetds library which works on Unix and Windows. The freetds community might be small but it is very active.
pbz 15y ago
Does anybody know how this affects ado.net? Would it make it slower / faster / no change? Would we have to change any of the code? Any features gained / lost? Thanks.
- duncans 15y ago
  Doesn't affect it. ADO.NET's SqlClient uses neither OLEDb nor ODBC. Uses direct TDS to the server.
  - jpitz 15y ago
    I was under the impression that ODBC, OLEDB and ADO.NET all spoke TDS on the wire.
dbattaglia 15y ago
The good news is that this shouldn't affect too many decently-written SQL Server-backed .Net applications at least (where you program against the base ADO.Net interfaces and factories). If I were using OleDB in a native/COM based application I might be a bit scared though!
- pyre 15y ago
  > There will be a seven-year phase-out period They definitely have time though...
prodigal_erik 15y ago
Spolsky once specifically used this stuff as an example of "cover fire" in one of the best insights I read about the industry. I guess this means nobody's following them closely enough anymore to duck when they shoot. http://www.joelonsoftware.com/articles/fog0000000339.html http://www.joelonsoftware.com/articles/fog0000000339.html
moomin 15y ago
It's worth noting that SQL server has a separate network path for ODBC (I believe). The announcement doesn't really say anything one way or the other about native drivers like SqlConnection in ADO.NET. Tbh, hardly anyone uses ADO, ADO.NET only really shares a name. I'm slightly curious about what they're going to do with the OLAP connectivity, though. ADO has always been the recommended approach.
Corrado 15y ago
At one point I worked with a MS SQL Server cluster and it required a special driver. This driver would do things like automatically switch ports/hosts depending on which box was the hot and which was the spare. I'm pretty sure we couldn't use the ODBC one because that was only driver that we could get (Java on AIX) and it didn't work well with the cluster.

52 points by xradionut 15y ago

gaius 15y ago

But what about TDS?

ximeng 15y ago
TDS is at the level below ODBC, shouldn't be affected I imagine.
aninteger 15y ago
Judging by stack traces ado.net is talking tds directly. Mono's implementation is based off freetds. Ruby has tinytds and of course existing c and c++ programmers can use the freetds library which works on Unix and Windows. The freetds community might be small but it is very active.

pbz 15y ago

Does anybody know how this affects ado.net? Would it make it slower / faster / no change? Would we have to change any of the code? Any features gained / lost? Thanks.

duncans 15y ago
Doesn't affect it. ADO.NET's SqlClient uses neither OLEDb nor ODBC. Uses direct TDS to the server.
- jpitz 15y ago
  I was under the impression that ODBC, OLEDB and ADO.NET all spoke TDS on the wire.

dbattaglia 15y ago

The good news is that this shouldn't affect too many decently-written SQL Server-backed .Net applications at least (where you program against the base ADO.Net interfaces and factories). If I were using OleDB in a native/COM based application I might be a bit scared though!

pyre 15y ago
> There will be a seven-year phase-out period They definitely have time though...

prodigal_erik 15y ago

Spolsky once specifically used this stuff as an example of "cover fire" in one of the best insights I read about the industry. I guess this means nobody's following them closely enough anymore to duck when they shoot. http://www.joelonsoftware.com/articles/fog0000000339.html http://www.joelonsoftware.com/articles/fog0000000339.html

moomin 15y ago

It's worth noting that SQL server has a separate network path for ODBC (I believe). The announcement doesn't really say anything one way or the other about native drivers like SqlConnection in ADO.NET. Tbh, hardly anyone uses ADO, ADO.NET only really shares a name. I'm slightly curious about what they're going to do with the OLAP connectivity, though. ADO has always been the recommended approach.

Corrado 15y ago

At one point I worked with a MS SQL Server cluster and it required a special driver. This driver would do things like automatically switch ports/hosts depending on which box was the hot and which was the spare. I'm pretty sure we couldn't use the ODBC one because that was only driver that we could get (Java on AIX) and it didn't work well with the cluster.