Por que o procedimento armazenado invalida a dependência do cache SQL?

Question

Depois de muitas horas, finalmente percebo que estou trabalhando corretamente com o objeto de cache no meu aplicativo ASP.NET, mas meus procedimentos armazenados impedem que ele funcione corretamente.

Este procedimento armazenado funciona corretamente:

CREATE PROCEDURE [dbo].[ListLanguages]
@Page INT = 1,
@ItemsPerPage INT = 10,
@OrderBy NVARCHAR (100) = 'ID',
@OrderDirection NVARCHAR(4) = 'DESC'
AS
BEGIN
    SELECT ID, [Name], Flag, IsDefault FROM dbo.Languages
END

Mas isso (o que eu queria) não:

CREATE PROCEDURE [dbo].[ListLanguages]
@Page INT = 1,
@ItemsPerPage INT = 10,
@OrderBy NVARCHAR (100) = 'ID',
@OrderDirection NVARCHAR(4) = 'DESC',
@TotalRecords INT OUTPUT
AS
BEGIN
    SET @TotalRecords = 10

EXEC('SELECT ID, Name, Flag, IsDefault FROM (
    SELECT ROW_NUMBER() OVER (ORDER BY ' + @OrderBy + ' ' + @OrderDirection + ') as Row, ID, Name, Flag, IsDefault
    FROM dbo.Languages) results
    WHERE Row BETWEEN ((' + @Page + '-1)*' + @ItemsPerPage + '+1) AND (' + @Page + '*' + @ItemsPerPage + ')')
END

Dei ao parâmetro @TotalRecords o valor 10, para que você possa ter certeza de que o problema não é da função Count (*) que eu sei que não é bem suportado.

Além disso, quando eu o executo no SQL Server Management Studio, ele faz exatamente o que deve fazer. No aplicativo ASP.NET, os resultados são recuperados corretamente, apenas o cache é de alguma forma incapaz de funcionar!

Você pode por favor ajudar?

Talvez uma dica

Acredito que a razão pela qual a propriedade de dependência está relacionada ao fato de a linha da coluna gerada a partir do row_number é apenas temporária e, portanto, o servidor SQL não pode dizer se os resultados são alterados ou não. É por isso que Haschanged está sempre definido como TRUE.

Alguém sabe como paginar os resultados do SQL Server sem usar as funções Count ou Row_Number?

Answer 1

A dependência do cache do SQL para .NET 3.5 funciona apenas para consultas simples. Talvez o .NET 4 me surpreenda.

Answer 2

Não é suficiente tamanho de cache.

Answer 3

1 - Você pode copiar e colar o código que você realmente usa para armazenar em cache os resultados desse sproc? 2 - Você já experimentou um sproc onde usa consulta direta em vez de executar uma string?

Sim #2 significa que você não pode alterar a estrutura da consulta em tempo real :-) Mas, a menos que você esteja calculando seus próprios critérios de armazenamento em cache no número 1, essa é a regra de armazenar em cache que você deve cumprir em geral. Nenhum mecanismo de armazenamento em cache jamais irá analisar uma corda do executivo de você.

Execução de uma string em um sproc faz com que o SPROC seja um toque total de uma moeda em cada execução, mesmo para o próprio SQL Server. Ele também deixa você aberto a ataques de injeção de scripts, já que sua consulta ainda está sendo composta por strings no tempo de execução - não é diferente de compor a sequência inteira em C# e passando para Sproc para "apenas executar o que quer que esteja dentro"