How is ADO related to OLE DB?

Question

Question

1. How is ADO related to OLE DB and what does mean the annoucement of Microsoft to drop OLE DB Providers for SQL Server mean?
2. Does it mean that if we switch to ADO it will not work with SQL Server 2014 and never?

Microsoft has announced the deprecation of the SQL Server Native Client OLE DB provider, and that SQL Server 2012 is the last version of SQL Server to support the provider.

Context

We are a Delphi shop. We are on Delphi 7 and BDE and want to migrate away from BDE, possibly also move to Delphi XE2 or newer. Our DBMS of choice is Microsoft SQL Server. We consider to move to ADO but are worried about it's future proofness in context of the above announcement.

Is this thinking of the relation ok? :

Delphi <---> ADO <---> OLE DB <---> DBMS

Do i understand correctly that Microsoft wants to move to?:

Delphi <---> ADO <---> OLE DB-bridge-ODBC <---> ODBC <---> DBMS

Answer 1

What they mean is that they will no longer be creating the SQL Server Native Client OLEDB Provider. There are a number of OLE DB Providers that you can use to access SQL Server:

• Microsoft OLE DB Provider for SQL Server (SQLOLEDB)

  This is the SQL Server 2000 era OLEDB Provider that ships with the operating system itself.

• SQL Native Client 9.0 OLE DB provider (SQLNCLI)

  • shipped with SQL Server 2005
  • must manually install on client PCs
  • can connect to SQL Server 7, 2000, and 2005
  • can connect to SQL Server 2008, but they recommend you use the new native client

• SQL Server Native Client 10.0 OLE DB Provider (SQLNCLI10)

  • shipped with SQL Server 2008
  • must manually install on client PCs
  • can connect to SQL Server 2000, 2005, 2008, and 2008 R2

• SQL Server Native Client 11.0 OLE DB Provider (SQLNCLI11)

  • shipped with SQL Server 2012
  • must manually install on client PCs
  • can connect to SQL Server 2005, 2008, 2008 R2, and 2012
  • will throw an error if used to connect to SQL Server 2000

Microsoft is going to cease creating new SQL Server Native Client OLEDB providers. All along they have been creating:

• SQL Native Client OLE DB provider
• SQL Native Client ODBC provider

They are going to stop creating the OLEDB provider drivers, while continuing the release the ODBC drivers. Meanwhile, the original SQLOLEDB driver still exists (even in Windows 10). You can continue to use ADO to access SQL Server. ADO is friendly wrapper around OLDDB (and ungainly beast of an API).

And inside OLE DB you can still use the old SQLOLEDB OLEDB driver.

You can also use the OLE DB provider that wraps an ODBC driver (MSDASQL):

• ADO
  • OLEDB
    • SQLOLEDB: Microsoft OLE DB Provider for SQL Server
    • SQLNCLI: SQL Native Client 9.0 OLE DB Provider
    • SQLNCLI10: SQL Server Native Client 10.0 OLE DB Provider
    • SQLNCLI11: SQL Server Native client 11.0 OLE DB Provider
    • MSDASQL: Microsoft OLE DB Provider for ODBC Drivers
      • {SQL Server}: SQLSRV32.dll
      • {SQL Server Native Client 10.0}: sqlncli10.dll
      • {SQL Server Native Client 11.0}: sqlncli11.dll

If you do move away from the old SQLOLEDB provider, and towards the ODBC drivers, you do have to beware of a subtle gotcha:

SQL Server does not support multiple open recordsets on one connection. For example, if you had some sort of master-detail:

sql := 'SELECT * FROM Orders';
qry := DatabaseHelper.Execute(sql);
while not qry.EOF do
begin
   //...

   //Oh, this order needs to be frobbed.
   DatabaseHelper.ExecuteNoRecords('UPDATE ORDERS SET Frob=1 WHERE OrderID='+IntToStr(orderID));

   qry.Next;
end;

You've just tried to do a second thing on a connection where a recordset is still being iterated. SQL Server doesn't support that. Fortunately the OLEDB provider knows this, and will silently open a second connection for you (a new spid and everything) to perform the action.

The ODBC drivers have no such helping hand. If you switch to using the ODBC driver, and didn't realize you have these subtle "issues" , your app will very quickly fall over dead.