¿Por qué el procedimiento almacenado invalidar Dependencia de Caché de SQL?

Question

Después de muchas horas, por fin me doy cuenta de que estoy trabajando correctamente con el objeto de Caché en mi ASP.NET aplicación pero mi procedimientos almacenados deja de funcionar correctamente.

Este procedimiento almacenado funciona correctamente:

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

Pero este (el que yo quería) no:

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

Me dio la @parámetro TotalRecords el valor de 10, de modo que usted puede estar seguro de que el problema no es de la función COUNT(*) que sé que no es compatible también.

También, cuando lo ejecuto desde SQL Server Management Studio, hace exactamente lo que debe hacer.En el ASP.NET aplicación de los resultados se recuperan correctamente, sólo la caché de alguna manera es incapaz de trabajar!

Puede usted por favor ayuda?

Tal vez una sugerencia

Creo que la razón por la que la dependencia HasChanged propiedad está relacionada con el hecho de que la columna de la Fila generado a partir de la ROW_NUMBER es sólo temporal y, por lo tanto, SQL SERVER no es capaz de decir si los resultados son modificados o no.Es por eso que HasChanged siempre se establece en true.

¿Alguien sabe cómo paginar los resultados de SQL SERVER sin el uso de RECUENTO o ROW_NUMBER funciones?

Answer 1

SQL dependencia de caché para .NET 3.5 sólo funciona para consultas sencillas. Tal vez .NET 4 me sorprenderá.

Answer 2

no es suficiente tamaño de la caché.

Answer 3

1 - ¿Se puede copiar y pegar el código que realmente utiliza para almacenar en caché los resultados de ese procedimiento almacenado? 2 - ¿Usted ha intentado un procedimiento almacenado en el que utiliza la consulta directamente en lugar de EXEC-ción de una cadena

?

Sí # 2 significa que no se puede cambiar la estructura de la consulta sobre la mosca :-) pero a menos que se está calculando sus propios criterios de almacenamiento en caché en el # 1 que es la regla de almacenamiento en caché que tiene que cumplir en general. No existe ningún mecanismo de almacenamiento en caché es cada vez va a analizar una cadena de EXEC de usted.

EXEC-ción de una cadena en un procedimiento almacenado hace que sproc una sacudida total de una moneda en cada plazo, incluso para SQL Server en sí. También te deja abierto a ataques de inyección guión ya la consulta todavía se está compuesta por cadenas en tiempo de ejecución - no es diferente de la composición de toda la cadena en C # y pasarla a sproc a "sólo EXEC lo que hay dentro"