Orientações de programação

Baixar driver ODBC

As funcionalidades de programação do Microsoft ODBC Driver para SQL Server em macOS e Linux baseiam-se no ODBC no SQL Server Native Client (SQL Server Native Client (ODBC)). O SQL Server Native Client baseia-se no ODBC nos Componentes de Acesso a Dados do Windows (ODBC Programmer's Reference).

Uma aplicação ODBC pode usar Múltiplos Conjuntos de Resultados Ativos (MARS) e outras funcionalidades específicas do SQL Server, incluindo /usr/local/include/msodbcsql.h depois de incluir os cabeçalhos unixODBC (sql.h, sqlext.h, sqltypes.h, e sqlucode.h). Depois usa os mesmos nomes simbólicos para itens específicos do SQL Server que usarias nas tuas aplicações ODBC do Windows.

Funcionalidades Disponíveis

As seguintes secções da documentação do SQL Server Native Client para ODBC (SQL Server Native Client (ODBC)) são válidas ao utilizar o driver ODBC no macOS e Linux:

• Comunicação com o SQL Server (ODBC)
• Suporte para tempo limite de conexão e consulta
• Cursors
• Melhorias de Data/Hora (ODBC)
• Executando consultas (ODBC)
• Tratamento de erros e mensagens
• Autenticação por Kerberos
• Tipos de User-Defined CLR grandes (ODBC)
• Transações de Execução (ODBC) (exceto transações distribuídas)
• Processamento de resultados (ODBC)
• Executando procedimentos armazenados
• Suporte a colunas esparsas (ODBC)
• Utilizar a Encriptação sem Validação
• Parâmetros Avaliados em Tabela
• UTF-8 e UTF-16 para API de comandos e dados
• Usando funções de catálogo

Funcionalidades Não Suportadas

As seguintes funcionalidades não foram verificadas para funcionar corretamente no driver ODBC no macOS e Linux:

• Ligação de Cluster de Failover
• Resolução IP de Rede Transparente (antes do Driver ODBC 17)
• Rastreamento BID do controlador ODBC para Linux e macOS (antes do Driver ODBC 17.3)

As seguintes funcionalidades não estão disponíveis no driver ODBC no macOS e Linux:

• Transações Distribuídas (SQL_ATTR_ENLIST_IN_DTC atributo não é suportado)
• Espelhamento de banco de dados
• FILESTREAM
• Perfilar o desempenho do driver ODBC, discutido no SQLSetConnectAttr, e os seguintes atributos de ligação relacionados com o desempenho:
  • SQL_COPT_SS_PERF_DATA
  • SQL_COPT_SS_PERF_DATA_LOG
  • SQL_COPT_SS_PERF_DATA_LOG_NOW
  • SQL_COPT_SS_PERF_QUERY
  • SQL_COPT_SS_PERF_QUERY_INTERVAL
  • SQL_COPT_SS_PERF_QUERY_LOG
• SQLBrowseConnect (antes da versão 17.2)
• Tipos de intervalo C, como SQL_C_INTERVAL_YEAR_TO_MONTH (documentados em Identificadores e Descriptores de Tipo de Dados)
• O valor SQL_CUR_USE_ODBC do atributo SQL_ATTR_ODBC_CURSORS da função SQLSetConnectAttr.

Suporte a conjuntos de caracteres

Para os drivers ODBC 13 e 13.1, os dados SQLCHAR devem ser UTF-8. Não são suportadas outras codificações.

Para o Driver ODBC 17, são suportados dados SQLCHAR num dos seguintes conjuntos de caracteres/codificações:

Ao ligar, o driver deteta a localização atual do processo em que está carregado. Se utilizar uma das codificações mencionadas acima, o driver usa essa codificação para dados SQLCHAR (carateres de largura reduzida); caso contrário, o padrão é UTF-8. Como todos os processos começam por defeito no local "C" (e fazem com que o driver passe por defeito para UTF-8), se uma aplicação precisar de usar uma das codificações acima, deve usar a função setlocale para definir o local adequadamente antes de se ligar; quer especificando explicitamente o local, quer usando uma cadeia vazia, por exemplo setlocale(LC_ALL, "") , para usar as definições locais do ambiente.

Portanto, num ambiente típico de Linux ou macOS onde a codificação é UTF-8, os utilizadores do ODBC Driver 17 que atualizam do 13 ou 13.1 não notarão diferenças. No entanto, aplicações que utilizam uma codificação não UTF-8 na lista setlocale() acima precisam de usar essa codificação para dados para/do driver em vez de UTF-8.

Os dados SQLWCHAR devem ser UTF-16LE (Little Endian).

Ao ligar parâmetros de entrada com SQLBindParameter, se for especificado um tipo SQL de carácter estreito como SQL_VARCHAR, o driver converte os dados fornecidos da codificação cliente para a codificação SQL Server padrão (tipicamente da página de código 1252). Para os parâmetros de saída, o driver converte da codificação especificada nas informações de ordenação associadas aos dados para a codificação do cliente. No entanto, a perda de dados é possível --- caracteres na codificação de origem não representáveis na codificação de destino se convertam num ponto de interrogação ('?').

Para evitar esta perda de dados ao ligar parâmetros de entrada, especifique um tipo de carácter Unicode SQL como SQL_NVARCHAR. Neste caso, o driver converte da codificação do cliente para UTF-16, que pode representar todos os caracteres Unicode. Além disso, a coluna ou parâmetro alvo no servidor deve também ser um tipo Unicode (nchar, nvarchar, ntext) ou um com uma colação/codificação, que possa representar todos os caracteres dos dados originais. Para evitar a perda de dados com parâmetros de saída, especifique um tipo SQL Unicode, e um tipo C Unicode (SQL_C_WCHAR), fazendo com que o driver devolva dados como UTF-16, ou um tipo C restrito, e garantir que a codificação do cliente pode representar todos os caracteres dos dados fonte (esta representação é sempre possível com UTF-8).

Para mais informações sobre colações e codificações, consulte Collation and Unicode Support.

Existem algumas diferenças de conversão de codificação entre o Windows e várias versões da biblioteca iconv no Linux e macOS. Os dados de texto na página de código 1255 (hebraico) têm um ponto de código (0xCA) que se comporta de forma diferente na conversão para Unicode. No Windows, este caractere é convertido para o ponto de código UTF-16 de 0x05BA. No macOS e Linux com versões libiconv anteriores à 1.15, converte-se para 0x00CA. No Linux com bibliotecas iconv que não suportam a revisão de 2003 do Big5/CP950 (nomeado BIG5-2003), os caracteres adicionados com essa revisão não convertem corretamente. Na página de código 932 (japonês, Shift-JIS), o resultado da decodificação de caracteres não originalmente definidos na norma de codificação também difere. Por exemplo, o byte 0x80 converte-se em U+0080 no Windows, mas pode tornar-se U+30FB no Linux e macOS, dependendo da versão do iconv.

Nos drivers do ODBC 13 e 13.1, a divisão de caracteres multibyte UTF-8 ou de substitutos UTF-16 entre buffers SQLPutData resulta em corrupção de dados. Utilize buffers para transmitir SQLPutData que não terminem em codificações parciais de caracteres. Esta limitação foi removida com o Driver ODBC 17.

OpenSSL

A partir da versão 17.4, o driver carrega o OpenSSL dinamicamente, o que permite que funcione em sistemas com versão 1.0 ou 1.1 sem necessidade de ficheiros separados do driver. A partir da versão 17.9, o driver suporta OpenSSL 3.0 além das versões anteriores. Quando existem várias versões do OpenSSL, o driver tenta carregar a mais recente.

Linux alpino

À data desta redação, o tamanho padrão da pilha no MUSL é 128K, o que é suficiente para funcionalidades básicas de drivers ODBC, no entanto, dependendo do que a aplicação faz, não é difícil ultrapassar este limite, especialmente ao chamar o driver a partir de múltiplas threads. Recomenda-se que uma aplicação ODBC em Alpine Linux seja compilada com -Wl,-z,stack-size=<VALUE IN BYTES> para aumentar o tamanho da pilha. Para referência, o tamanho padrão da pilha na maioria dos sistemas GLIBC é de 2MB.

Notas adicionais

• Pode criar uma ligação dedicada de administrador (DAC) usando autenticação SQL Server e host, port. Um membro do cargo de Sysadmin precisa primeiro de descobrir a porta do DAC. Consulte Conexão de Diagnóstico para Administradores de Bases de Dados para descobrir como. Por exemplo, se a porta DAC fosse 33000, poderia aceder-lhe da seguinte forma sqlcmd:

  sqlcmd -U <user> -P <pwd> -S <host>,33000
  

  Observação

  As ligações ao DAC devem usar Autenticação SQL Server.

• O gestor de drivers UnixODBC devolve "identificador de atributo/opção inválido" para todos os atributos da instrução quando são passados pelo SQLSetConnectAttr. No Windows, quando SQLSetConnectAttr recebe um valor do atributo da instrução, o driver configura esse valor em todas as instruções ativas, que são descendentes do handle da conexão.

• Ao utilizar o driver com aplicações altamente multithreaded, a validação de handle pelo unixODBC pode tornar-se um gargalo de desempenho. Nesses cenários, pode ser obtido um desempenho superior compilando unixODBC com a --enable-fastvalidate opção. No entanto, atenção que esta opção pode fazer com que aplicações que passem handles inválidos para APIs ODBC crashem em vez de devolverem SQL_INVALID_HANDLE erros.

Ver também

Perguntas Mais Frequentes
Problemas conhecidos nesta versão do driver
Notas de versão