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.
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.
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.
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!
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.
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.
http://www.joelonsoftware.com/articles/fog0000000339.html