Microsoft’s Eric Nelson has posted about how the OLEDB driver for SQL Server is being deprecated and will not be supported beyond “Denali”, the forthcoming version.
OLEDB was created to be the successor to ODBC – expanding the supported data sources/models to include things other than relational databases. Notably OLEDB was tightly tied to a Windows only technology (COM) whilst ODBC was not (Although we did try and take COM cross platform via partners)
ODBC never did get replaced. What actually happened is that ODBC remained the dominant of the two technologies for many scenarios – and became increasingly used on none Windows platforms and has become the de-facto industry standard for native relational data access.
ODBC was as I recall Microsoft’s first attempt at creating a universal database API.
The death of OLEDB will be slow, according to Nelson. The OLEDB driver for Denali will be supported for seven years following Denali’s release. He also says that OLEDB itself, as opposed to the SQL Server OLEDB driver, is not necessarily being deprecated; though frankly if Microsoft ceases supporting it with its own database I cannot see much future for it.
Note that ADO.NET, which to some extent replaced OLEDB, is not being deprecated. However ADO.NET is only usable from .NET applications. When you consider that Microsoft may be to some extent tilting away from .NET and towards native code, the deprecation of OLEDB becomes even more significant.
ODBC is not particularly easy to use in its raw form. However, you can wrap ODBC with, yes, an OLEDB provider or an ADO.NET provider; or you can wrap the whole lot in an object-relational framework such as Entity Framework.
One more chapter in the long, strange and tortuous history of Microsoft’s data APIs.
I’ve been testing the new Community Tech Preview of SQL Server 2011, codenamed “Denali”.
Here is an intriguing feature. You can now create a new kind of table called a FileTable. A FileTable is mapped to a folder on the filesystem, though you are not meant to access it directly once it is managed by SQL Server. However, you can access the folder in Windows Explorer, or over the network, as a network share. When you do this, a SQL Server component intercepts the Windows API calls and updates the FileTable. FileTables build on the existing FILESTREAM feature in SQL Server 2008, and the documents in the folder are stored as FILESTREAM data.
The illustration shows a folder in Windows Explorer that is also a SQL Server FileTable.
Is this the return of WinFS, the fabled relational file system which was originally planned for Windows Longhorn, but abandoned? Not really. According to the docs:
FileTables remove a significant barrier to the use of SQL Server for the storage and management of unstructured data that is currently residing as files on file servers. Enterprises can move this data from file servers into FileTables to take advantage of integrated administration and services provided by SQL Server. At the same time, they can maintain Windows application compatibility for their existing Windows applications that see this data as files in the file system.
At Oracle OpenWorld yesterday I spoke to an attendee from a global enterprise. His company is a big IBM customer and would like to standardise on DB2. To some extent it does, but there is still around 30% Oracle and significant usage of Microsoft SQL Server. Why three database platforms when they would prefer to settle on one? Applications, which in many cases are only certified for a specific database manager.
I was at MySQL Sunday earlier in the day, and asked whether he had any interest in Oracle’s open source database product. As you would expect, he said it was enough trouble maintaining three different systems; the last thing he wanted was a fourth.