Principais diferenças de versão no Microsoft ODBC Driver for SQL Server

Este artigo descreve mudanças de impacto entre o Driver 18 do Microsoft ODBC para SQL Server e a versão 17. Use quando escolher uma versão do driver, atualizar um aplicativo da versão 17 para a 18, ou precisar fazer uma cadeia de conexão funcionar de forma consistente em ambas as versões.

A maioria dos aplicativos que atualizam da versão 17 para a versão 18 é afetada por uma única alteração: as conexões são criptografadas por padrão. Se sua aplicação para de se conectar após a atualização, leia primeiro o comportamento padrão de criptografia .

Escolha a versão 17 ou a versão 18

Driver 18 é a versão principal atual. O Driver 17 continua suportado, mas os aplicativos que o utilizam ainda precisam da versão menor mais recente da linha Driver 17 para receber correções. Para datas de suporte e regras de serviço, veja ciclo de vida do suporte.

Scenario Caminho recomendado
Nova aplicação Comece pelo Driver 18. Configure criptografia e validação de certificados antes da produção.
Aplicação existente do Driver 17 Instale o Driver 18 junto com o Driver 17, mude o nome do driver na cadeia de conexão ou DSN, e defina Encrypt explicitamente. Se a validação do certificado falhar, corrija o certificado do servidor ou o repositório de confiança do cliente.
Aplicação que precisa Encrypt=Strictde , HostnameInCertificate, RetryExec, ou outra palavra-chave do Driver 18 Use uma versão do Driver 18 que suporte essa configuração. O driver 17 não aceita o Strict valor de Encrypt e não reconhece as novas palavras-chave.
Aplicação que precisa de fixação de arquivo certificado com ServerCertificate Use o driver 18.1 ou uma versão posterior com Encrypt=Strict. O driver 17 não suporta essa configuração.

Mudar de versão principal geralmente significa mudar o nome do driver ou o pacote que você escolhe:

Platform Piloto 17 Piloto 18
Nome do driver da string de conexão ODBC Driver 17 for SQL Server ODBC Driver 18 for SQL Server
Nome do pacote Linux msodbcsql17 msodbcsql18

Resumo das alterações

As linhas padrão e de validação descrevem conexões remotas comuns sem configuração DSNEncrypt, atributo SQL_COPT_SS_ENCRYPT ou substituição de Criptografia do Protocolo Forçado do Windows. O LocalDB não é um alvo remoto TLS.

Area Versão 17 Versão 18 e versões posteriores
Configuração padrão Encrypt no, a menos que Authentication seja definido para um valor diferente de none ou a aplicação define SQL_COPT_SS_ACCESS_TOKEN; então yes yes (18.0.1 e posteriores)
Encrypt Valores aceitos yes, no yes, no, Mandatory, Optional, Strict
Modos de criptografia De vez em quando Desligada, ligada ou rígida
Validação do certificado do servidor Com Encrypt=yes;TrustServerCertificate=no, valida o certificado. Só a criptografia exigida pelo servidor não seleciona validação. Valida por padrão. Em modos não Strict, pula TrustServerCertificate=yes a validação normal, inclusive quando o servidor precisa de criptografia.
Palavras-chave de cadeia de conexão Conjunto base Conjunto base mais novas palavras-chave

Alterações de criptografia

Comportamento de criptografia padrão

O driver 17 tem Encrypt=no como padrão a menos que a Authentication palavra-chave seja definida para um valor diferente de none ou a aplicação defina o SQL_COPT_SS_ACCESS_TOKEN atributo. Qualquer um deles muda o padrão para yes. Um still explícito Encrypt=no desativa a criptografia. Driver 18.0.1 e posteriores são padrão para Encrypt=yes. Define Encrypt explicitamente quando você comparar versões.

A criptografia de conexão completa protege o texto da consulta e os resultados, assim como o login. Com , o servidor ainda pode exigir criptografia Encrypt=node conexão total. Quando tanto o cliente quanto o servidor selecionam a criptografia desligada, a negociação não-Estrita usa criptografia apenas de login; isso não protege os dados subsequentes da aplicação.

Com , ambos os drivers selecionam Encrypt=yes;TrustServerCertificate=noa validação normal do certificado do servidor. Se apenas o servidor exigir criptografia de conexão total e TrustServerCertificate=no (o padrão), o Driver 18 valida o certificado. Com TrustServerCertificate=yes o modo Strict fora do Driver, o Driver 18 pula essa validação. O driver 17 não valida apenas por causa desse requisito do servidor. A criptografia do Windows Force Protocol e os caminhos internos de validação de certificados não são cobertos por essa comparação.

Com as configurações padrão de criptografia, atualizar da versão 17 para a versão 18 pode expor um certificado de servidor não confiável. Se a versão 18 rejeitar o certificado, diagnostique a cadeia de certificados e o nome antes de alterar as configurações de autenticação.

Mantenha a criptografia e a validação de identidade do servidor ativadas:

  • Configure um certificado válido do servidor e o repositório de confiança do cliente para que o cliente confie na autoridade certificadora emissora. Conecte-se usando um nome no certificado.
  • Se você se conectar por um alias, defina HostnameInCertificate um nome válido no certificado do servidor. Essa configuração não repara uma cadeia de certificados não confiável.
  • Para Encrypt=Strict, o Driver 18.1 e versões posteriores também suportam ServerCertificate a comparação do certificado do servidor com um arquivo de certificado. Essa configuração fixa um certificado; não especifica um nome de host. Revise as restrições dele no ODBC DSN e nas palavras-chave de cadeia de conexão antes de usá-lo.

Caution

Para um ambiente de teste isolado, Encrypt=yes;TrustServerCertificate=yes solicita criptografia, mas pula a validação da identidade do servidor, deixando a conexão aberta a ataques adversários no meio. Não use como reparo de confiança de produção. No modo Rigoroso, TrustServerCertificate é ignorado.

Se uma aplicação existente requer o padrão da versão 17 durante um teste de compatibilidade controlado, veja Restaurar comportamento de criptografia da versão 17. Encrypt=no E Encrypt=optional não repare a confiança do certificado e pode deixar os dados da aplicação sem criptografia.

Valores de criptografia

A versão 17 aceita apenas yes e no. A versão 18 e versões posteriores aceitam esses valores e adicionam mais três:

Value Equivalente a Behavior
Mandatory yes A conexão é criptografada.
Optional no Não solicita criptografia de conexão total. O servidor ainda pode exigir isso; criptografia apenas de login não é proteção para sessão completa.
Strict None A conexão utiliza criptografia TDS 8.0. O servidor deve suportar TDS 8.0, como SQL Server 2022 e versões posteriores.

Strict não possui equivalente à versão 17. É o único valor que seleciona o TDS 8.0, onde a criptografia é negociada antes da troca de login, e não durante ela.

Restaurar comportamento de criptografia da versão 17

Após revisar as correções de trust, use a seguinte configuração apenas para um teste de compatibilidade controlado que permita dados de aplicação não criptografados:

Encrypt=no

O driver 18 também aceita Encrypt=optional essa configuração. Nenhum dos valores impede que o servidor precise de criptografia. Restaure a configuração criptografada pretendida após o teste; não use criptografia desativada como remédio de confiança no certificado.

Lista de verificação de upgrade

  1. Strings de conexão de inventário, DSNs, referências de pacotes e scripts de implantação que selecionam o Driver 17.
  2. Instale o Driver 18 em um ambiente de teste que corresponda à produção.
  3. Mude a Driver palavra-chave em cada cadeia de conexão para ODBC Driver 18 for SQL Server, e atualize ou recrie cada DSN para usar o Driver 18. Instalar o Driver 18 não troca as conexões existentes, porque as conexões que nomeiam o Driver 17 continuam usando o Driver 17.
  4. Defina Encrypt explicitamente. Use Encrypt=Mandatory com validação normal de certificados. Use Encrypt=Strict apenas quando o servidor suporta TDS 8.0, como SQL Server 2022 e versões posteriores. Para servidores que não suportam TDS 8.0, use Encrypt=Mandatory.
  5. Para validação normal, conecte-se e TrustServerCertificate=no verifique a cadeia confiável e o nome do servidor aceito. Para o Driver 18.1 e versões posteriores com fixação de arquivos Strict, verifique a correspondência exata dos certificados e as datas de validade; TrustServerCertificate é ignorado no modo Strict.
  6. Execute os caminhos de autenticação, consulta, transação, cópia em massa, failover e retentativas da aplicação.
  7. Revise os diagnósticos para erros de validação de certificados antes de tratar falhas como erros de autenticação ou de rede.
  8. Mantenha o Driver 17 instalado e mantenha o inventário desde a etapa 1 até a validação ser concluída, para que você possa voltar para a versão 17.

Voltar para a versão 17

O Driver 17 e o Driver 18 são instalados lado a lado, então você pode voltar sem desinstalar o Driver 18. Para detalhes de download e instalação, veja Download ODBC Driver for SQL Server.

  1. Confirme se o Driver 17 ainda está instalado em cada cliente.
  2. Usando o inventário da checklist de atualização, mude a Driver palavra-chave em cada cadeia de conexão de volta para ODBC Driver 17 for SQL Server.
  3. Atualize ou recrie cada DSN para usar o Driver 17.
  4. Reverta referências de pacotes e scripts de implantação para o pacote Driver 17, como msodbcsql17 no Linux.
  5. Restaure os Encrypt valores e TrustServerCertificate que a aplicação usou com o Driver 17. O Driver 17 aceita apenas yes e no para Encrypt e não reconhece palavras-chave do Driver 18 como HostnameInCertificate ou ServerCertificate, então remova valores e palavras-chave adicionadas para o Driver 18. Mude as palavras-chave dos alias de volta para os nomes do Driver 17 e substitua ConnectTimeout por uma SQLSetConnectAttr chamada que defina SQL_ATTR_LOGIN_TIMEOUT. Para o mapeamento, veja Novas palavras-chave de cadeia de conexão.

Valide o rollback antes de considerá-lo completo:

  • Cada conexão reporta o Motorista 17. Chame SQLGetInfo com SQL_DRIVER_VER; a versão principal é 17.
  • Os caminhos de autenticação, consulta, transação, cópia em massa, failover e retentativa da aplicação são bem-sucedidos.
  • Strings de conexão e DSNs não Encrypt contêm valores ou palavras-chave adicionados para o Driver 18.

Novas palavras-chave de cadeia de conexão

A versão 18 adiciona as seguintes palavras-chave de cadeia de conexão, que a versão 17 não reconhece. Alguns deles são novos nomes para configurações que a versão 17 suporta sob uma palavra-chave ou atributo diferente, listados na coluna equivalente da Versão 17 .

Keyword Versão mínima Purpose Equivalente à versão 17
ConcatNullYieldsNull 18.6 Determina se concatenar um valor nulo gera valor nulo. None
ConnectTimeout 18.7 Define o tempo limite de login em segundos. Se a aplicação também define SQL_ATTR_LOGIN_TIMEOUT, o atributo tem precedência. SQL_ATTR_LOGIN_TIMEOUT atributo, definido com SQLSetConnectAttr
FailoverPartner 18.7 Especifica o parceiro de failover para espelhamento de banco de dados. Apenas para Windows. Failover_Partner palavra-chave
GetDataExtensions 18.0 Controle quais SQLGetData extensões o driver permite. None
HostnameInCertificate 18.0 Especifica o nome do host a validar no certificado TLS do servidor. None
IpAddressPreference 18.1 Especifica a família de endereços IP que o driver tenta primeiro. None
LongAsMax 18.0 Mapeia tipos de dados longos para seus max equivalentes. None
MultipleActiveResultSets 18.7 Permite múltiplos conjuntos de resultados ativos (MARS). Aceita Yes ou No. MARS_Connection palavra-chave
RetryExec 18.1 Configura regras de retentativa para consultas falhadas. None
ServerCertificate 18.1 Especifica o arquivo de certificado para corresponder ao certificado do servidor ao usar Encrypt=Strict. None
WorkstationID 18.7 Especifica o nome da estação de trabalho enviado ao servidor. WSID palavra-chave

MultipleActiveResultSets, WorkstationID, e FailoverPartner são apelidos que alinham nomes-chave ODBC com Microsoft.Data.SqlClient nomes de propriedades. A versão 18 também aceita os nomes mais antigos. Para detalhes, veja Unificação de palavras-chave de string de conexão e palavra-chave ConnectTimeout.

Para a referência completa de palavras-chave, veja ODBC DSN e cadeia de conexão palavras-chave.

Conteúdo relacionado

  • Última atualização em