Un buen motivo para paginar es pasarle menos data al cliente y aligerar el
tráfico y velocidad de respuesta.

Alguien alguna vez me inculcó que lo último que hay que intentar es ejecutar
SQL dinámico por el tema que no se compila, y además por temas de seguridad,
y desde ahí la palabra me suena a pecado.

Igualmente si una autoridad en el tema como vos lo dice… tan terrible no
debe ser. ;-)

De todas maneras encontré la forma de hacerlo. Lo que hice es nullear el
campo de ordenamiento si no se cumple la condición y poner la otra condición
en un CASE nuevo así no comparten el mismo CASE campos de distinto tipo.

 

ROW_NUMBER() OVER(ORDER BY 

CASE WHEN UPPER(@orderBy) = 'CONDGEN_ID' AND @orderType = 0 THEN condGen_Id
ELSE null END ASC,

CASE WHEN UPPER(@orderBy) = 'CONDGEN_NOMBRE' AND @orderType = 0 THEN
condGen_Nombre ELSE null END ASC,

CASE WHEN UPPER(@orderBy) = 'CONDGEN_ID' AND @orderType = 1 THEN condGen_Id
ELSE null END DESC,

CASE WHEN UPPER(@orderBy) = 'CONDGEN_NOMBRE' AND @orderType = 1 THEN
condGen_Nombre ELSE null END DESC) AS nRow

 

En todos los casos el costo de ordenamiento me viene tirando lo mismo. No es
lo más óptimo, pero es lo que hay ;-)

 

Saludos

Leonardo

  _____  

De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Jose Mariano
Alvarez
Enviado el: Jueves, 21 de Junio de 2007 03:59 a.m.
Para: Leonardo Ghigliani
Asunto: [dbms] Re: Paginado y ordenación dinámica SQL2005

 

Nunca encontre un buen motivo para paginar pero no usaria esa forma sino SQL
Dinamico con buen control de parametros para que no inyecten codigo. 

 

Saludos



-- 
-------------------------------- 
Atte.
Ing. Jose Mariano Alvarez
SQL Total Consulting 

 

 



 

On 6/18/07, Leonardo Ghigliani <[EMAIL PROTECTED]> wrote: 

Buenas. A ver si me tiran una soga. No hace mucho que me pasé a SQL 2005

Estoy tratando de incorporar ordenamiento dinámico en una consulta paginada
a una tabla. 

Estoy usando el ROW_NUMBER OVER() de MS SQL 2005 para paginar

El problema que tengo es que me está tirando un error de conversión no sé
porqué al evaluar la expresión de ordenamiento. 

Antes que nada, ya sé, no me digan… el CASE afecta la performance, pero es
lo único que se me ocurrió hasta ahora. Si hay un mejor método, por favor
corríjanme. 

 

El código de la Stored es el siguiente:

 

CREATE PROCEDURE [dbo].[EntidadListar] 

@startRowIndex int,

@maximumRows int,

@orderBy tinyint,

@Count int = null output 

AS

BEGIN

      SELECT nRow, Entidad_Id , Entidad_Nombre

      FROM  

            (SELECT ROW_NUMBER() OVER (ORDER BY 

                  CASE @orderBy

                        WHEN 0 THEN Entidad_Id

                        WHEN 1 THEN Entidad_Nombre 

                  END 

DESC

            ) as nRow ,

            Entidad_Id, 

            Entidad_Nombre

            FROM Entidad

            WHERE Entidad_Activo = 1 

            ) As Entidad_Temp 

      WHERE nRow BETWEEN @startRowIndex 

AND (@startRowIndex + @maximumRows) - 1  

      SET @Count = @@ROWCOUNT

END 

 

Me está tirando el siguiente error:

Msg 245, Level 16, State 1, Procedure EntidadListar, Line 9

Conversion failed when converting the varchar value 'Texto de la primer
ocurrencia de Entidad_Nombre' to data type int.

 

Sin embargo, si dejo el ROW_NUMBER() OVER(ORDER BY Entidad_Nombre DESC)
funciona perfecto.

 

Otro problema (que dejé para solucionar después de este) es que no puedo
hacer dinámico el sentido de ordenamiento. 

Si pongo por ejemplo 

 

CASE  

WHEN @orderBy = 0 THEN Entidad_Id ASC  

WHEN @orderBy = 1 THEN Entidad_Id DESC

WHEN @orderBy = 2 THEN Entidad_Nombre ASC

WHEN @orderBy = 3 THEN Entidad_Nombre DESC  

END

 

Me tira un error de sintaxis en los ASC y DESC finales. Tampoco funciona
poniendo después otro CASE para el ASC y DESC (aunque ya sería un abuso de
CASE) 

 

Gracias

Leonardo

 

 

 

Responder a