Delphi with SQL Server: OLEDB vs. Native Client drivers

Question

I have been told that SQL Native Client is supposed to be faster than the OLEDB drivers. So I put together a utility to do a load-test between the two - and am getting

Answer 1

You cannot use the native clients with ADO, as is.

ADO does not understand the XML SQL Server data type. The field type:

field: ADOField;

field := recordset.Fields.Items["SomeXmlColumn"];

Attempting to access field.Value throws an EOleException:

• Source: Microsoft Cursor Engine
• ErrorCode: 0x80040E21 (E_ITF_0E21)
• Message: Multiple-step operation generated errors. Check each status value

The native client drivers (e.g. SQLNCLI, SQLNCLI10, SQLNCLI11) present an Xml data type to ADO as

field.Type_ = 141 

While the legacy SQLOLEDB driver presents an Xml data type to ADO as adLongVarWChar, a unicode string:

field.Type_ = 203 //adLongVarWChar

And the VARIANT contained in field.Value is a WideString (technically known as a BSTR):

TVarData(field.Value).vtype = 8 //VT_BSTR

The solution, as noted by Microsoft:

Using ADO with SQL Server Native Client

Existing ADO applications can access and update XML, UDT, and large value text and binary field values using the SQLOLEDB provider. The new larger varchar(max), nvarchar(max), and varbinary(max) data types are returned as the ADO types adLongVarChar, adLongVarWChar and adLongVarBinary respectively. XML columns are returned as adLongVarChar, and UDT columns are returned as adVarBinary. However, if you use the SQL Server Native Client OLE DB provider (SQLNCLI11) instead of SQLOLEDB, you need to make sure to set the DataTypeCompatibility keyword to "80" so that the new data types will map correctly to the ADO data types.

They also note:

If you do not need to use any of the new features introduced in SQL Server 2005, there is no need to use the SQL Server Native Client OLE DB provider; you can continue using your current data access provider, which is typically SQLOLEDB.