A connection manager asks for a provider, and an old package offers three familiar names. OLE DB or ODBC is a choice about the tool you use and the driver you will maintain.

Start With the Consumer of OLE DB or ODBC
ODBC and OLE DB are data access APIs. Your application, package, or SQL Server feature decides which one it can use. Do not choose by a vague claim that one is always faster. The supported driver and the actual workload matter more.
I ask which component opens the connection. An SSIS OLE DB connection manager needs an OLE DB provider. An ODBC application needs an ODBC driver. A SQL Server linked server to SQL Server commonly uses a supported OLE DB provider. The API choice is already shaped by the consumer.
What needs to keep working after the change: a nightly package, a linked query, or a customer application? Name the path before changing a provider string.
Know the Old Provider Names
Older systems can show SQLNCLI, SQLNCLI11, or SQLOLEDB. SQL Server Native Client is no longer the recommended starting point for new development, and it is not shipped with newer SQL Server and Management Studio releases. SQLOLEDB is a legacy Windows provider. Seeing an old name in a package is a migration task, not a reason to panic.
Microsoft’s current OLE DB Driver for SQL Server uses MSOLEDBSQL19 for version 19. MSOLEDBSQL also appears in supported configurations, with version behavior depending on the installed driver and component. Check the exact documentation for the path you use.
I inventory names before installing a new driver. Installation alone does not rewrite a package or linked server. The old connection can keep using the old provider.
Choose a Current ODBC Driver
Microsoft’s ODBC Driver for SQL Server is the supported ODBC path for new Windows applications that use that API. It also underpins familiar command line tools. Install a supported release on each client host and test the application’s connection settings.
ODBC data sources can exist in user or system scope and in different Windows platform views. A driver visible to one process is not automatically visible to another. Match application architecture and deployment context. Check the actual service account and execution machine.
A driver major update can change encryption defaults. Test certificate trust and server name validation in staging. The first failure after a driver update can be a certificate error, not a broken SQL query.
# PowerShell
Get-OdbcDriver |
Where-Object Name -Like '*SQL Server*' |
Select-Object Name, Platform, AttributeChoose OLE DB for the Right Component
For an SSIS package with an OLE DB connection manager, use the supported Microsoft OLE DB Driver for SQL Server and update the package connection configuration. Test design time and runtime. The package can execute on a different host from the one where you edited it.
For linked servers, review provider support for your SQL Server build. Newer driver encryption behavior can require explicit certificate and connection settings. Test a read and the actual application query. A linked server that opens but fails on a data type conversion is not done.
I treat provider migration as a controlled application change. A package that runs once in development is useful evidence, but the production execution account and host still need testing.

Inventory Linked Server Providers
SQL Server exposes linked server configuration in sys.servers. The provider column shows the configured OLE DB provider for a linked server. Use it to find old names before a server upgrade. Keep sensitive connection details out of a public report.
The query below lists the local names and providers. It does not reveal which jobs use each linked server. Search module definitions, Agent steps, and application code for that dependency. A linked server can sit idle for weeks before a monthly report calls it.
I review the provider list before patching or moving to a new major version. A small query can prevent a late surprise in a batch job.
SELECT
name AS LinkedServerName,
product,
provider
FROM sys.servers
WHERE is_linked = 1
ORDER BY name;Test OLE DB or ODBC Security Defaults
Both driver families have evolved around encryption and authentication. A newer client can reject an untrusted certificate or a server name mismatch. Do not turn validation off as the permanent fix without a security decision. Provide the correct certificate and trusted chain.
Run the test through the real component. A successful ODBC test does not validate an SSIS OLE DB connection. A successful Management Studio login does not validate a linked server. Record the driver version, provider name, connection options, and exact SQL Server build.
Check the established session’s encrypt_option when you can run a diagnostic query through that component. It confirms the successful connection, not a failed attempt that never reached login.
SELECT
net_transport,
encrypt_option,
auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;Measure OLE DB or ODBC on the Application Path
If performance is the reason for changing API, compare the same workload through both supported configurations. Use actual results, plans, and measured timings. Driver changes can alter parameter types, batching, and conversion. A bare connection benchmark says little about a production ETL path.
Keep correctness first. Check Unicode text, decimal precision, dates, NULLs, large values, and error handling. A package that completes with truncated data is worse than one that stops loudly.
I have seen a driver blamed for a query plan chosen because the application sent a different parameter type. Capture the submitted SQL and types before declaring a winner.
Make the Choice Maintainable
Record the selected provider, version, installation location, owner, and update process. Keep application and server patch cycles coordinated. A supported engine with a forgotten client driver can still fail at the next security change.
Remove legacy providers only after you have found every dependent package and job. Observe a complete relevant schedule, including monthly work. Keep an exception with an owner and end date for anything that cannot move yet.
OLE DB or ODBC is a practical compatibility choice. Pick the supported driver that fits the component, then prove the real workload works with it.
Related reading on this blog: The OLE DB Provider "Microsoft.ACE.OLEDB.12.0" for Linked Server "(null)" Reported an Error. Access Denied and SSIS: Package Error: "ODBC Source" Failed Validation and Returned Validation Status "VS_NEEDSNEWMETADATA".

The API label is not a performance trophy, it is a maintenance choice for the component that connects.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
Discover more from SQL Authority with Pinal Dave
Subscribe to get the latest posts sent to your email.





1 Comment. Leave new
i have installed sql2008 r2 64bit on WinSBS2011 64, i am unable to install sqlserver2005_bc.msi. error says os not supported.
is there any other solution, like converting dts2005 packages into ISS