Recebi um caso em que um cliente está enfrentando esse erro - de vez em quando:
Msg 8624, Nível 16, Estado 21, Linha 1
Erro interno do processador de consulta: O processador de consulta não pôde produzir um plano de consulta. Para mais informações, contacte os Serviços de Apoio ao Cliente.
Eles estão usando nosso software e executando-o no SQL Server 2008 R2 (RTM) e no nível de compatibilidade 100 (SQL Server 2008). O banco de dados, no entanto, foi originalmente criado em uma máquina de 2000 ou 2005 (não pode mais ser reproduzido) e depois movido para 2008 R2 recentemente.
O procedimento armazenado em questão tem uma declaração de aparência feia INSERTque obtém dados de dez (sim!) "cópias" de uma determinada tabela, todas unidas RIGHT OUTER JOINentre si (mesma tabela - dez JOINs contra ela).
A única solução que achei mais adequada tem a ver com várias configurações - é recomendável usar:
set ANSI_NULLS ON
set ANSI_PADDING ON
set ANSI_WARNINGS ON
set CONCAT_NULL_YIELDS_NULL ON
set QUOTED_IDENTIFIER ON
set ARITHABORT ON
set NUMERIC_ROUNDABORT OFF
OK - claro - posso defini-los antes de cada procedimento armazenado que criar (ou alterar).
Minha pergunta para os gurus do banco de dados seria: algum risco quando eu definir essas configurações como padrão para meu banco de dados?
Por exemplo
ALTER DATABASE MyDB SET ANSI_NULLS ON
e acabar com isso? Pensamentos? Percepções? Recomendações?
Não é um risco de forma alguma. Na verdade, a capacidade de desligar
ANSI_NULLStem uma vida útil limitada. Em breve isso nem será uma opção, sempre estará ON . A única vez que vi qualquer forma de raciocínio para definirANSI_NULLSOFF , é porque há desenvolvedores que não conseguem entender o verdadeiro significado deNULLe, portanto, desejam usar a lógica condicional típica com ele. Mais uma vez, raciocínio terrível e injustificável. Estou ansioso para a configuração ON permanente paraANSI_NULLS.