No SQL Server 2016, como posso garantir o uso do Microsoft ODBC Driver 13 para SQL Server em um servidor vinculado? Não me importo de haver outra camada lá, como o provedor MSDASQL, mas quero que o driver ODBC 13 para SQL Server seja o que acaba fazendo a conexão com a instância de remoção.
Com o teste no SQL Server 2016 RC2 no Windows 2016 Technical Preview 4, ambas novas instalações em uma VM em branco, posso usar o odbcad32 para ver o "ODBC Driver 13 para SQL Server", versão 2015.130.1300.275, com nome de arquivo MSODBCSQL13.DLL.
A versão e o nome do arquivo são idênticos na tela odbcad32 de 64 bits, bem como na tela odbcad32 de 32 bits de c:\windows\syswow64, portanto, não acredito que seja um problema de 32 x 64 bits no momento (particularmente desde que o driver foi instalado pela instalação do SQL Server 2016 RC2).
No SQL 2014, por exemplo, para usar o Native Client 11, eu usaria
EXEC master.dbo.sp_addlinkedserver @server = N'LinkName', @srvproduct=N'sql_server', @provider=N'SQLNCLI11', @datasrc=N'YourTargetServer'
No SQL 2016 RC2, quando tento
EXEC master.dbo.sp_addlinkedserver @server = N'LinkName', @srvproduct=N'sql_server', @provider=N'MSODBCSQL13', @datasrc=N'YourTargetServer'
O servidor vinculado cria muito bem, mas quando tento usá-lo, recebo:
Msg 7403, Level 16, State 1, Line 7
The OLE DB provider "MSODBCSQL13" has not been registered.
Não tive sorte tentando nomes de provedores de ODBC Driver 13 para SQL Server Microsoft ODBC Driver 13 para SQL Server
ou mesmo tentando combinações disso que o nome do provedor MSDASQL, de
Usando o Always Encrypted com o Windows ODBC Driver e sp_addlinkedserver (Transact-SQL)
E mesmo olhando pelo registro não revelou um nome de provedor que eu reconheci.
Observe que o uso do odbcad32 para criar um DSN do sistema é, de fato, testado com sucesso quando escolho o ODBC Driver 13 para SQL Server, então sei que pode funcionar.
Idealmente, eu quero apenas um exemplo de comando sp_addlinkedserver que especifique o novo driver ODBC nele.
Não é possível usar apenas ODBC. Os servidores vinculados usam consultas distribuídas que dependem da interface OLEDB. Esta não é uma API opcional ou intercambiável. Abaixo dessa API pode estar qualquer provedor OLEDB, ODBC ou mesmo JDBC, desde que sua implementação suporte a interface OLEDB. Por exemplo, há um provedor OLEDB para ODBC, que é uma das formas mais comuns de executar DQ em fontes de dados não SQL Server. O SQL Server oferece suporte nativo a OLEDB, portanto, não há necessidade de camada extra. A maioria/todas essas informações podem ser encontradas em Books Online ou MSDN.
Por que você precisa usar apenas ODBC? Se desejar para Always Encrypted, sugira que você registre uma solicitação de recurso via https://connect.microsoft.com/SQLServer/feedback/ . Não sei se o cenário é compatível onde você executa AE por meio de DQ. A "chamada do SQL Server" essencialmente se torna o cliente para o "SQL Server de destino", mas você não controla totalmente o cliente, pois o DQ não é algo que você pode modificar.
Se for por algum outro motivo, compartilhe detalhes aqui para que as pessoas ajudem a encontrar soluções alternativas.
É verdade que os servidores vinculados dependem da interface OLEDB, mas o driver ODBC pode ser usado com segurança entre servidores SQL Server. (Há um equívoco de que tal configuração não é suportada pela Microsoft; isso é um mito.)
Para usar o driver ODBC 11, 13 ou 13.1 usando servidores vinculados.
O driver ODBC 13.1 é uma atualização e ainda usa o nome do driver "ODBC Driver 13 para SQL Server", não "ODBC Driver 13.1 para SQL Server".
Descobri que usar o nome do servidor totalmente qualificado parece, em meus testes, ser mais confiável, especialmente ao conectar-se a AGs, mas você sempre pode tentar apenas o nome do servidor.
Você pode testar a conectividade Kerberos entre servidores, mas usando um OPENROWSET. Uma maneira de testar o Kerberos é usando uma consulta simples executada no servidor de origem:
Se você vir esse erro, precisará configurar o Kerberos entre os servidores:
O 2012 Native Client já tem (mais) cinco anos, foi oficialmente obsoleto pela Microsoft e, se você quiser se alinhar ao roteiro da Microsoft, deverá usar o ODBC. Considere que em 2014, o 2012 Native Client tinha apenas dois anos. Agora considere todos os recursos adicionados ao SQL Server 2016 e SQL Server 2017 que não são suportados pelo 2012 Native Client, e você terá um ótimo caso de uso para usar o ODBC Driver 13.1 para SQL Server.
Desde meados do ano passado, minha organização está migrando para o SQL Server 2016 e estamos testando o SQL Server 2017 (CTP 2.1). Tenho migrado todos os nossos servidores vinculados (pelo menos aqueles que apontam para SQL Server 2016 ou SQL Server 2017) para usar o ODBC Driver 13 (ou, mais precisamente, 13.1) e ainda não vi nenhum problema sério em mais de um ano de testes contra o SQL Server 2016.
(No interesse da divulgação completa, há um problema com tabelas gráficas usando servidores vinculados; relatei o problema à Microsoft com base em um servidor vinculado usando ODBC 13.1 e a Microsoft confirmou que as tabelas gráficas não são suportadas por servidores vinculados (de qualquer tipo) no SQL Server 2017.)
Deixe-me saber se você tiver quaisquer problemas e eu vou ajudá-lo.