[Shordi]

Aquí tenéis el enlace al quinto vídeo de la serie sobre la Extensión de Gridview. He sufrido lo indecible para ajustarlo a 15 minutos, que me he propuesto que sea el límite de tamaño.
Con esta entrega podéis ver que se pueden ordenar varias columnas indistintamente ascendentes o descendentes. El sistema no es perfecto, lo sé, por ejemplo, la decisión de si una celda es un número o es una cadena de caracteres se hace celda a celda, por lo que si las columnas mezclan valores alfabéticos con valores numéricos, el comportamiento de la ordenación de esa columna es impredecible. Todo se puede controlar, claro, pero para el ejemplo valga así.
Diseñé en su día estos comportamientos del control para ahorrar accesos a las bases de datos. Con este vídeo de hoy simulamos la cláusula Order By de una consulta sql sencilla sin necesidad de recurrir a nuestra base de datos otra vez.

Espero que os sea útil.
En el los dos próximos vídeos añadiremos la capacidad de hacer filtros (cláusula where de la sentencia Select) sin necesidad de recurrir a la BBD tampoco.

Saludos.

[tincho]

Diseñé en su día estos comportamientos del control para ahorrar accesos a las bases de datos. Con este vídeo de hoy simulamos la cláusula Order By de una consulta sql sencilla sin necesidad de recurrir a nuestra base de datos otra vez.

Perfecto, no me convence lo de hacer cosas fuera de una consulta sql, pero le echare un ojo. seguro que me convences como cuando no quería usar las colecciones.
Supongo que es para optimizar el flujo de datos.
 

Aquí tenéis el enlace al quinto vídeo de la serie sobre la Extensión de Gridview. He sufrido lo indecible para ajustarlo a 15 minutos, que me he propuesto que sea el límite de tamaño.

Felicitaciones !! estas hecho todo un Youtuber.

Saludos

[Shordi]

Perfecto, no me convence lo de hacer cosas fuera de una consulta sql, pero le echare un ojo. seguro que me convences como cuando no quería usar las colecciones.
Supongo que es para optimizar el flujo de datos.

El tema es que, a veces, la consulta a la BD paga un precio muy alto en tiempos. Estos controles heredados de GridView (y otros de TreeView, combobox, etc) los diseñé en su momento, hace un montón de tiempo, basando todo en consultas contra un servidor MySql. Cada filtro, cada ordenación, cada rellenado de un combobox, etc. era una consulta a la BD (a veces un formulario complejo podía hacer hasta 20 consultas antes de ser mostrado) y me funcionaban de maravilla... en mi puesto de trabajo, es decir: a metro y medio del servidor que tenía montado en mi despacho. Me manejé con ellos y nadie se me quejó, de entrada. Un día, en un viaje de trabajo a Guadalajara (unos 300 km), accedí a mi programa y quedé pasmado ¡Tardaba casi 7 segundos en cada consulta y cada ordenación!

"¿Siempre es así de lento?" Pregunté. "Bueno... hay días malos, no como hoy", me respondieron.

A partir de ahí empecé a investigar en ésta línea. Estoy contigo que lo más fiable es la BBDD y que, si estás trabajando con un Sqlite con 300 registros en local o con un Mysql en red local, la demora es prácticamente instantánea, etc. Sin embargo, sigo defendiendo mi línea de trabajo porque no interfiere en los datos.

Quiero decir que los datos, cuando provienen de una consulta a una BD, vienen (deberían venir) depurados y normalizados. Lo digo por la carencia que comentaba arriba de si hay datos "mezclados" de números y dígitos, etc.. Se supone que en la BD ya han pasado los "controles de calidad". Si provienen de otra fuente, como un .csv o una hoja de cálculo o lo que sea, digamos que la responsabilidad de la "pureza" del dato es algo previo a mostrarlo en un GridView con "propósitos decisorios".

Quiero decir que si te pasan un .csv y tú lo miras con este control, verás lo que tiene, pero no puedes tomar decisiones seguras basándote sólo en eso. Todo .csv, cuando su propósito es ser añadido a una BD, debe pasar un "control de calidad" y un proceso de depuración primero. Así, si, por ejemplo, contiene campos de fecha, habrá que verificar que cumplen el formato de fecha que usemos, si tienen campos numéricos con decimales, que el punto o la coma sean los apropiados a nuestro idioma, etc. etc.

Pero todo esto es (debería ser) previo a la visualización en pantalla con "propósito decisorio". Utilizo éste término cuando quieres tomar decisiones significativas en la empresa a partir del resultado que el extGrid ofrece. Si por el contrario sólo lo usas "para ver lo que tiene el .csv", ya sabes que no puedes fiarte del control... ni del .csv ni de quien te lo envió, claro.

Decir que todo este rollo es significativo cuando estás en el mundo profesional. Ahí hay que encontrar siempre un equilibro entre fiabilidad y funcionalidad. Toma un ejemplo de internet: Salvo la primera vez y cuando haya cambios significativos, lo que ves en pantalla nunca está sacado directamente de la BD, hay montones de capas intermedias de caché que te dan velocidad y funcionalidad... a riesgo de que lo que estás viendo no sea exactamente lo que hay almacenado. Con esto es lo mismo... pero menos. La validez de la información (salvo bugs y deficiencias, claro) es de unos segundos/minutos de desfase.

Saludos