Cita:
Empezado por Casimiro Notevi
jaja... eso es trampa 
He estado probando a fondo las distintas metodologías que se han propuesto y todas terminan por "fallar" en alguna condición, aunque es cierto que "casi no se enteraría nadie"  y no le darían mucha importancia, pero si se quiere hacer las cosas bien entonces he tenido que desestimar todas las que usan el método de controlar los registros anteriores y similares. Simplemente no pueden funcionar, por lógica, salvo que el usuario se mueva de principio a fin con las teclas, registro a registro, y eso no suele ser lo más habitual en este caso, ya que es el grid de consulta principal del programa y además donde se validarán los registros que se "dan por buenos", en fin, que va a ser seguramente lo más muy usado del programia.
Creo que ha quedado demostrado que la única opción totalmente segura y válida para esta tarea es que en el propio registro se tenga un campo o dato del que se extraiga el color, así es independiente por completo de los movimientos que haga el usuario por el grid, use tecla o ratón, haga lo que haga. Siempre se pintará el registro con los datos extraidos de sí mismo, no hay error.
Pensé de hacerlo con una tabla en memoria pero no me convencía porque tras hacer el select había después que pasar los datos a esa tabla, no sólo por el tiempo (que es rápido normalmente) sino también por consumo de memoria ram y porque habría que traerse todos los registros, y esto es algo que nunca me ha gustado hacer.
Finalmente he optado por el método de la base de datos, concretamente es un Store Procedure que además de los campos del registro se trae también un campo 'color'.
No es tampoco lo que me hubiese gustado hacer porque son muchos filtros los que puede usar el usuario y hay que pasarle muchos parámetros al SP, la mayoría son del tipo "si pasas este parámetro no hay que pasar el otro", así que finalmente he tenido que optar por una opción 'híbrida', desde delphi se monta la sentencia sql y se llama al SP únicamente con ese parámetro, luego en el SP se hace un 'execute statement sentencia' y listo.
He estado haciendo pruebas y de momento, por lo que he podido ver, va bien, es ágil y parece que funciona correctamente con todas las combinaciones.
Y ya está bien por hoy, que son casi las 8 de la mañana y aquí estoy todavía, ya creo que no me voy a ir a dormir, enlazaré el día... bueno, voy a prepararme un café y a asomarme a la ventana, que empieza a amanecer
Quiero dar las gracias a todos porque me ha servido para ir probando distintas modalidades y finalmente optar por la que pienso que me viene mejor. Sin vuestra ayuda hubiese tardado muchísimo más. Os debo una invitación de "tapa de jamón y cerveza"
MUCHAS GRACIAS A TODOS
p.d.: Y no doy esto por cerrado, si alguien descubre una manera fiable de hacerlo mediante la GUI... se lleva el jamón  |
Estoy con Casimirro.
Desde el primer momento me pareció que la solución estaba en tener la infomación en los registros. No he tenido tiempo de pensar en código ni de probar las soluciones que se daban.
Valoré, en un primer momento la posibilidad de las tablas en memoria, pero lo descarté por las mismas razones, y que en entornos multipuesto pueden llegar a "mentir" bastante (si no se recargan convenientemente).
Desde mi punto de vista, una solución que no debe costar (ni tiempo ni dinero, creo que era una premisa) es válida si no es demasiado mala. Es decir, que a veces, pequeñas "trampas" son necesarias en busca de la productividad.
En este caso, con el Store Procedure, si hay pocos puestos, no creo que la pérdida de rendimiento sea significativa. Y si hay muchos, probablemente habrá recursos suficientes para tomar medidas (unas pocas horas más para hacer pruebas, o gastar un poco de dinero en "algo" que lo resuelva).
No defiendo el todo vale mientras funcione. Pero en entornos empresariales, hemos de optimizar sobre todo el tiempo. Si necesito 10-12 horas para resolver un tema como este, me compensa más comprar un componente (que no se si lo hay) de 300 €, que además me dará otras ventajas que no tengo en un grid normal.
El código (o la solución en general), es mejor o peor si se puede comprobar que en situaciones similares, ofrecen respuestas distintas. Si el resultado es similar (tiempo de respuesta, uso de CPU y/o memoria, etc) ambos son válidos como solución. Otra cosa es comparar códigos fuente, horas de programación, legibilidad, etc.
Todo esto son opiniones personales y no afirmaciones categóricas.
Saludos,