Roxana: *Paginación del GridView* Por defecto, cuando uno habilita la paginación del *GridView* esta paginación *no ocurre a nivel de datos*. Esto significa, que si tengo 1000 registros y los muestro de a 10, el *GridView* simplemente pagina esos regsitros mostrando de a 10, pero los 1000 registros ya fueron leídos de la BD, y dependiendo de cómo hayas traído esos registros para pasarlos al GridView, puede que estés leyendo una y otra vez esos 1000 registros.
Los controles *DataSource* como ObjectDataSource, SqlDataSource o LinqDataSource puede ayudar un poco cacheando los 1000 registros y evitando multiples consultas de la misma información a la BD. Este mecanismo no es tan malo para muchos escenarios. Sin embargo, *¿por qué traer 1000 registros si solo voy a mostrar 10?*. Es decir, si voy a mostrar 10 registros, seguramente me interesa obtener de la BD solo esos 10 registros, ni más ni menos. Para lograr eso *la paginación debe ocurrir a nivel de datos*. *Consultas Paginadas* Escribir *consultas SQL paginadas* suele ser un poco duro. Además, *para que la grilla sepa cuantas páginas tiene que dibujar*, necesitarás también una consulta adicional para saber *cuantos registros hay en total*. En SQL Server (creo desde SQL2005 en adelante), podrás utilizar la función * row_number*() para escribir consultas que devuelven resultados en forma paginada. Por ejemplo: create procedure [dbo].[Expense_GetSubmitters] @TenantId uniqueidentifier, @StartRow int = null, @MaxRows int = null as begin with query as ( select row_number() over (order by FullName) as Row, * from AgentView as a where a.TenantId = @TenantId ) select * from query where (Row between @StartRow and @StartRow + @MaxRows) end *Paginación con ADO.NET Entity Framework* Si estás usando *LINQ2SQL* o *ADO.NET Entity Framework*, puede que te interese este post que escribí hace un tiempo: http://gustavoazcona.blogspot.com/2009/03/paginacion-y-ordenamiento-del-lado.html Aquí explico cómo implementar paginación y ordenamiento a nivel de datos usando ADO.NET EF (con LINQ2SQL es idéntico). Y aunque no estés usando ninguno de estos "ORMs", el post puede aclararte un poco más acerca de la problemática de implementar paginación con GridView y paginación a nivel de datos. Espero que sirva. *Saludos, Gus* El 21 de noviembre de 2009 09:43, Roxana Leituz <[email protected]>escribió: > Muchisimas gracias a todos por las respuestas!! Oscar: son registros de > solo lectura, no se deben tocar porque son informes de estado para un ente > público, pero el cliente hoy los genera ciegamente y quiere al menos > "verlos" antes de generar el txt. Pero son muchisimos. Voy a comenzar las > pruebas. > Muchisimas gracias por las sugerencias, > Saludos > Roxana > > ----- Original Message ----- > *From:* [email protected] > *To:* [email protected] > *Sent:* Friday, November 20, 2009 11:00 AM > *Subject:* [puntonet] manejo de memoria en la paginacion > > Un ejercicio que se puede hacer en estos casos es poner un break point en > el método que maneja el evento de carga de la página, reproducir el evento > que se quiere conocer (seleccionar un item de la paginación, en este caso) y > seguir a partir del break point para ver qué tipo de consulta se hace. > También podría ser realizar un trace a la base de datos y ver qué consultas > se realizan y cuándo. > > Pero yendo a lo más específico, me imagino que sí. No lo puedo asegurar > porque no sé cómo está construida tu página, pero el funcionamiento del grid > view es como lo estás describiendo. > > Entre las soluciones posibles, podrías crear tu custom grid view que > realizara el query específico para cada página o podrías implemetar un > patrón DTO para almacenar la información de la tabla una sola vez y > después bindear tu grid o cualquier control con ese objeto o, un poco más > simple, crear un object data source que para cada página devuelva los > registros necesarios (podés encontrar cientos de ejemplos en Internet, te > paso uno que encontré en una búsqueda rápida en google: > http://www.dotnetcurry.com/ShowArticle.aspx?ID=267&AspxAutoDetectCookieSupport=1 > ). > > Tené en cuenta que la performance también está dada por el desempeño de la > consulta en la base de datos, si tenés acceso: revisá el diseño de las > tablas, el diseño de las consultas, los planes de ejecución y los índices > necesarios en las tablas. > > > > C.S. > > > *----- Original Message -----* > *From:* Oscar Onorato [mailto:[email protected]] > *To:* [email protected] > *Sent:* Fri, 20 Nov 2009 01:21:01 -0300 > *Subject:* [puntonet] manejo de memoria en la paginacion > > Roxana, > > Depende para qué estás recuperando esos registros. Si son para sólo lectura > es un tema y si son para editar es otro. > Sería bueno saber eso, por el tipo de consulta que vas a hacer. Más allá > del paginado. > > Espero tu respuesta, > > Saludos, > > Oscar > > El 19 de noviembre de 2009 22:35, Roxana Leituz <[email protected] > > escribió: > > Hola!! queria saber si tienen idea de que manera utiliza asp.net el tema > de la paginación. cuando uso una grilla y habilito la paginación, el sistema > carga toda la tabla en memoria o va trayendo los registros en la medida que > los requiero?? pregunto esto porque necesito levantar una cantidad > importante de registros y saber si lo tengo que hacer "a mano" , usando > row_count por ejemplo. Se aceptan ideas.. > Muchas gracias!! > > > > -- Gustavo Azcona
