Partilhar via

Problemas conhecidos no SqlClient para Entity Framework

  • Artigo

Esta seção descreve problemas conhecidos relacionados ao Provedor de Dados do .NET Framework para SQL Server (SqlClient).

Espaços à direita em funções de cadeia de caracteres

O SQL Server ignora espaços à direita em valores de cadeia de caracteres. Portanto, passar espaços à direita na cadeia de caracteres pode levar a resultados imprevisíveis, até mesmo falhas.

Se você precisar ter espaços à direita em sua cadeia de caracteres, considere acrescentar um caractere de espaço em branco no final, para que o SQL Server não corte a cadeia de caracteres. Se os espaços à direita não forem necessários, eles devem ser cortados antes de serem passados pelo pipeline de consulta.

Função DIREITA

Se um não-valornull for passado como um primeiro argumento e 0 for passado como um segundo argumento para RIGHT(nvarchar(max), 0) ou RIGHT(varchar(max), 0), um NULL valor será retornado em vez de uma empty cadeia de caracteres.

Operadores CROSS e OUTER APPLY

Os operadores CROSS e OUTER APPLY foram introduzidos no SQL Server 2005. Em alguns casos, o pipeline de consulta pode produzir uma instrução Transact-SQL que contém operadores CROSS APPLY e/ou OUTER APPLY. Como alguns provedores de back-end, incluindo versões do SQL Server anteriores ao SQL Server 2005, não oferecem suporte a esses operadores, essas consultas não podem ser executadas nesses provedores de back-end.

A seguir estão alguns cenários típicos que podem levar à presença de operadores CROSS APPLY e/ou OUTER APPLY na consulta de saída:

  • Uma subconsulta correlacionada com paginação.

  • Uma AnyElement sobre uma subconsulta correlacionada ou sobre uma coleção produzida pela navegação.

  • Consultas LINQ que usam métodos de agrupamento que aceitam um seletor de elementos.

  • Uma consulta na qual um CROSS APPLY ou um OUTER APPLY é explicitamente especificado

  • Uma consulta que tem uma construção DEREF sobre uma construção REF.

Operador SKIP

Se você estiver usando o SQL Server 2000, usar SKIP com ORDER BY em colunas não-chave pode retornar resultados incorretos. Mais do que o número especificado de linhas pode ser ignorado se a coluna não-chave tiver dados duplicados nela. Isso se deve a como SKIP é traduzido para o SQL Server 2000. Por exemplo, na consulta a seguir, mais de cinco linhas podem ser ignoradas se E.NonKeyColumn tiver valores duplicados:

SELECT [E] FROM Container.EntitySet AS [E] ORDER BY [E].[NonKeyColumn] DESC SKIP 5L

Direcionando a versão correta do SQL Server

O Entity Framework destina-se à consulta Transact-SQL com base na versão do SQL Server especificada no ProviderManifestToken atributo do elemento Schema no arquivo de modelo de armazenamento (.ssdl). Esta versão pode ser diferente da versão do SQL Server real ao qual você está conectado. Por exemplo, se você estiver usando o SQL Server 2005, mas seu ProviderManifestToken atributo estiver definido como 2008, a consulta Transact-SQL gerada pode não ser executada no servidor. Por exemplo, uma consulta que usa os novos tipos de data e hora que foram introduzidos no SQL Server 2008 não será executada em versões anteriores do SQL Server. Se você estiver usando o SQL Server 2005, mas seu ProviderManifestToken atributo estiver definido como 2000, a consulta Transact-SQL gerada pode ser menos otimizada ou você pode obter uma exceção que diz que a consulta não é suportada. Para obter mais informações, consulte a seção Operadores CROSS e OUTER APPLY, anteriormente neste tópico.

Certos comportamentos de banco de dados dependem do nível de compatibilidade definido para o banco de dados. Se o ProviderManifestToken atributo estiver definido como 2005 e a versão do SQL Server for 2005, mas o nível de compatibilidade de um banco de dados estiver definido como "80" (SQL Server 2000), o Transact-SQL gerado terá como destino o SQL Server 2005, mas poderá não ser executado conforme o esperado devido à configuração de nível de compatibilidade. Por exemplo, você pode perder informações de pedido se um nome de coluna na lista ORDER BY corresponder a um nome de coluna no seletor.

Consultas aninhadas na projeção

As consultas aninhadas em uma cláusula de projeção podem ser traduzidas em consultas de produto cartesianas no servidor. Em alguns servidores back-end, incluindo o SQL Server, isso pode fazer com que a tabela TempDB fique bastante grande. Isso pode diminuir o desempenho do servidor.

Segue-se um exemplo de uma consulta aninhada numa cláusula de projeção:

SELECT c, (SELECT c, (SELECT c FROM AdventureWorksModel.Vendor AS c  ) As Inner2 FROM AdventureWorksModel.JobCandidate AS c  ) As Inner1 FROM AdventureWorksModel.EmployeeDepartmentHistory AS c

Valores de identidade GUID gerados pelo servidor

O Entity Framework oferece suporte a valores de identidade de tipo GUID gerados pelo servidor, mas o provedor deve oferecer suporte ao retorno do valor de identidade gerado pelo servidor após a inserção de uma linha. A partir do SQL Server 2005, você pode retornar o tipo de GUID gerado pelo servidor em um banco de dados do SQL Server por meio da cláusula OUTPUT.

Consulte também