Atualizando um aplicativo do MDAC para o SQL Server Native Client
Há várias diferenças entre o SQL Server Native Client e o MDAC (Microsoft Data Access Components; desde o Windows Vista, os componentes de acesso aos dados agora são chamados de Windows DAC, ou Windows Data Access Components). Ainda que ambos forneçam acesso a dados em bancos de dados do SQL Server, o SQL Server Native Client foi especificamente projetado para expor os novos recursos do SQL Server 2005, ao mesmo tempo em que mantém a compatibilidade com versões anteriores.
As informações deste tópico ajudam a atualizar o aplicativo MDAC (ou Windows DAC) em relação à versão do SQL Server Native Client incluída no SQL Server 2005. Para ajudar na atualização desse aplicativo em relação à versão do SQL Server Native Client fornecida com o SQL Server 2008 R2, consulte Atualizando um aplicativo do SQL Server 2005 Native Client para o SQL Server 2008 R2 Native Client.
Além disso, muito embora o MDAC contenha componentes para usar OLE DB, ODBC e ADO (ActiveX Data Objects), o SQL Server Native Client implementa apenas OLE DB e ODBC (ainda que o ADO possa acessar a funcionalidade do SQL Server Native Client).
O SQL Server Native Client e o MDAC são diferentes nas demais áreas a seguir:
Aqueles que usam o ADO para acessar um provedor do SQL Server Native Client podem encontrar menos funcionalidade de filtragem do que quando acessam um provedor OLE DB SQL.
Se um aplicativo do ADO usar o SQL Server Native Client e tentar atualizar uma coluna computada, será informado um erro. Com o MDAC, a atualização foi aceita, mas ignorada.
O SQL Server Native Client é um único arquivo DLL (biblioteca de vínculo dinâmico) autossuficiente. As interfaces expostas publicamente foram mantidas no mínimo, tanto para facilitar a distribuição quanto para limitar a exposição de segurança.
Só há suporte para interfaces OLE DB e ODBC.
O provedor OLE DB do SQL Server Native Client e os nomes do driver ODBC são diferentes dos usados com o MDAC.
A funcionalidade acessível ao usuário fornecida pelos componentes do MDAC está disponível quando o SQL Server Native Client é usado. Isso inclui, mas não se limita a, o seguinte: pool de conexões, suporte ao ADO e suporte ao cursor do cliente. Quando algum desses recursos é usado, o SQL Server Native Client fornece apenas conectividade de banco de dados. O MDAC fornece funcionalidades como, por exemplo, rastreamento, controles de gerenciamento e contadores de desempenho.
Os aplicativos podem usar os serviços principais do OLE DB com o SQL Server Native Client, mas caso usem o mecanismo de cursor do OLE DB, eles devem usar a opção de compatibilidade do tipo de dados para evitar problemas em potencial que possam surgir em decorrência do desconhecimento dos novos tipos de dados do SQL Server 2005 pelo mecanismo de cursor.
O SQL Server Native Client oferece suporte ao acesso a bancos de dados do SQL Server anteriores a partir do SQL Server 7.0 e das versões mais novas.
O SQL Server Native Client não contém integração de XML. O SQL Server Native Client oferece suporte a consultas SELECT … FOR XML, mas não a qualquer outra funcionalidade XML. No entanto, o SQL Server Native Client oferece suporte ao tipo de dados xml introduzido no SQL Server 2005.
O SQL Server Native Client oferece suporte à configuração de bibliotecas de rede do lado do cliente que usam apenas atributos da cadeia de conexão. Caso precise de uma configuração de biblioteca de rede mais completa, você deve usar o SQL Server Configuration Manager.
O SQL Server Native Client não é compatível com odbcbcp.dll. Os aplicativos que usam APIs tanto ODBC quanto bcp devem ser recriados para que sejam vinculados a sqlncli10.lib e usem o SQL Server Native Client.
Não há suporte para o SQL Server Native Client no Microsoft OLE DB Provider for ODBC (MSDASQL). Se você estiver usando o driver MDAC SQLODBC com MSDASQL ou o driver MDAC SQLODBC com ADO, use OLE DB no SQL Server Native Client.
As cadeias de conexão MDAC permitem um valor booleano (true) para a palavra-chave Trusted_Connection. Uma cadeia de conexão do SQL Server Native Client deve usar yes ou no.
As alterações menores ocorreram por conta de avisos e erros. Avisos e erros retornados pelo servidor agora mantêm a mesma severidade quando passados para o SQL Server Native Client. Você não deve se esquecer de testar integralmente o aplicativo caso dependa da interceptação de avisos e erros específicos.
O SQL Server Native Client apresenta uma verificação de erro mais rígida do que o MDAC, o que significa que alguns aplicativos que não se adaptam rigidamente às especificações do ODBC e do OLE DB podem se comportar de maneira diferente. Por exemplo, o provedor SQLOLEDB não impunha a regra de que os nomes de parâmetro devem começar com '@' em parâmetros de resultado, mas o provedor OLE DB do SQL Server Native Client, sim.
O SQL Server Native Client se comporta de maneira diferente em relação ao MDAC no que diz respeito a falhas de conexão. Por exemplo, o MDAC retorna valores de propriedade armazenados em cache para uma falha de conexão, ao passo que o SQL Server Native Client informa um erro ao aplicativo de chamada.
O SQL Server Native Client não gera eventos do Analisador do Visual Studio, e sim eventos de rastreamento do Windows.
O SQL Server Native Client não pode ser usado com perfmon. Perfmon é uma ferramenta do Windows que só pode ser usada com DSNs que usem o driver SQLODBC do MDAC incluído no Windows.
Quando o SQL Server Native Client é conectado ao SQL Server 2005, um erro de servidor 16947 é retornado como SQL_ERROR. Esse erro ocorre quando uma atualização ou exclusão posicionada deixa de atualizar ou excluir uma linha. Com o SQL Server 2000 e as versões anteriores, e com o MDAC em meio à conexão com qualquer versão do SQL Server, o erro de servidor 16947 é retornado como um aviso (SQL_SUCCESS_WITH_INFO).
O SQL Server Native Client implementa a interface IDBDataSourceAdmin, que é uma interface OLE DB opcional não implementada anteriormente, mas apenas o método CreateDataSource dessa interface opcional é implementado. Esse recurso será removido em uma versão futura do Microsoft SQL Server. Evite usar esse recurso em desenvolvimentos novos e planeje modificar os aplicativos que atualmente o utilizam.
O provedor OLE DB do SQL Server Native Client retorna sinônimos nos conjuntos de linhas de esquema TABLES e TABLE_INFO, com TABLE_TYPE definido como SYNONYM.
Valores de retorno do tipo de dados varchar(max), nvarchar(max), varbinary(max), xml, udt ou outros tipos de objeto grandes não podem ser retornados a versões do cliente anteriores ao SQL Server 2005. Caso queira usar esses tipos como valores de retorno, você deve usar o SQL Server Native Client.
O MDAC permite que as seguintes instruções sejam executadas no início das transações manuais e implícitas, mas o SQL Server Native Client, não. Elas devem ser executadas no modo de confirmação automática.
Todas as operações de texto completo (indexar e catalogar DDL)
Todas as operações de banco de dados (criar, alterar, descartar banco de dados)
Reconfiguração
Desligamento
Eliminação
Backup
Quando os aplicativos do MDAC se conectarem ao SQL Server, os tipos de dados introduzidos no SQL Server 2005 serão exibidos como tipos de dados compatíveis com o SQL Server 2000, como mostrado na seguinte tabela.
Tipo SQL Server 2005
Tipo SQL Server 2000
varchar(max)
text
nvarchar(max)
ntext
varbinary(max)
image
udt
varbinary
xml
ntext
Esse mapeamento de tipo afeta os valores retornados para metadados da coluna. Por exemplo, uma coluna text tem um tamanho máximo de 2.147.483.647, mas o ODBC do SQL Server Native Client informa o tamanho máximo das colunas varchar(max) como SQL_SS_LENGTH_UNLIMITED e o OLE DB do SQL Server Native Client informa o tamanho máximo das colunas varchar(max) como 2.147.483.647 ou -1, dependendo da plataforma.
O SQL Server Native Client permite ambiguidade em cadeias de conexão (por exemplo, algumas palavras-chave podem ser especificadas mais de uma vez e outras, conflitantes, permitidas tendo a resolução baseada na posição ou na precedência) tendo em vista a compatibilidade com versões anteriores. Futuras versões do SQL Server Native Client talvez não permitam ambiguidade em cadeias de conexão. Trata-se de uma boa prática, ao modificar aplicativos, usar o SQL Server Native Client para eliminar todas as dependências relacionadas à ambiguidade da cadeia de conexão.
Caso você use uma chamada ODBC ou OLE DB para iniciar transações, existe uma diferença de comportamento entre o SQL Server Native Client e o MDAC. As transações começarão imediatamente com o SQL Server Native Client, e só começarão no MDAC depois do primeiro acesso ao banco de dados. Isso pode afetar o comportamento de procedimentos armazenados e lotes porque o SQL Server exige que @@TRANCOUNT seja o mesmo de quando o lote o ou procedimento armazenado começou após a conclusão da execução. Consulte Reversões e confirmações em procedimentos armazenados e disparadores para obter mais informações.
Com o SQL Server Native Client, ITransactionLocal::BeginTransaction fará com que uma transação seja iniciada imediatamente. Com o MDAC, o início da transação foi atrasado até que o aplicativo executasse uma instrução que exigia uma transação em modo de transação implícita. Para obter mais informações, consulte SET IMPLICIT_TRANSACTIONS (Transact-SQL).
Você pode encontrar erros ao usar o driver do SQL Server Native Client com System.Data.Odbc para acessar um computador de servidor do SQL Server que expõe novos tipos de dados ou recursos específicos do SQL Server. System.Data.Odbc fornece uma implementação de ODBC genérica e, dessa forma, não expõe funcionalidades ou extensões específicas do fornecedor. (O driver do SQL Server Native Client é atualizado para oferecer suporte nativo aos recursos mais recentes do SQL Server.) Como solução alternativa para esse problema, é possível voltar ao MDAC ou migrar para System.Data.SqlClient.
Tanto o SQL Server Native Client quanto o MDAC oferecem suporte ao isolamento de transação de leitura confirmada usando controle de versão de linha, mas apenas o SQL Server Native Client oferece suporte ao isolamento da transação de instantâneo. (Em termos de programação, o isolamento de transação de leitura confirmada usando controle de versão de linha é a mesma coisa que transação de leitura confirmada.) Para obter mais informações, consulte Escolhendo níveis de isolamento baseados em controle de versão de linha.