Instead, use the new Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL) which will be updated with the most recent server features. If you know your installed SQL server version, determine whether your current version of SQL Server already has support for TLS 1.2.
Go to this link and you will find SQL Server release and the first build that supports TLS 1.2. And theres a download link under this text. Before you proceed further you need to know the SQL native client version that you have to download. The previous Microsoft OLE DB Provider for SQL Server (SQLOLEDB) and SQL Server Native Client OLE DB provider (SQLNCLI) remain deprecated and it is not recommended to use either for new development work. This redistributable installer for SQL Native Client installs the client components needed during run time to take advantage of new SQL Server 2005 features, and optionally installs the header files needed to develop an application that uses the SQL Native Client API. The OLE DB provider is expected to be registered with the specified PROGID in the registry. Using SQLNCLI will redirect SQL Server to the latest version of SQL Server Native Client OLE DB Provider. provider_name is nvarchar(128), with a default of NULL however, if provider_name is omitted, SQLNCLI is used. provider_name must be unique for the specified OLE DB provider installed on the current computer. Is the unique programmatic identifier (PROGID) of the OLE DB provider that corresponds to this data source. The irony here is that Microsoft has been trying to deprecate SQLNCLI11 for years - and yet even as late as SQL 2019, Replication setup still creates linked servers using SQLCNLI11 under the hood! Not only that, since the driver doesn't support multi-subnet aware, our AlwaysOn automatic publisher redirect fails whenever we failover our Publisher to a replica in a different subnet than our distribution server! Go figureįrom their documentation on sp_addlinkedserver (the default client is SQLNCLI )
0 kommentar(er)
