Alternar colores en dbgrid

[[fjcg02]]

Repasando el hilo completo, Delphius ya daba el 80 % de la solución cuando en su post adjuntaba el código del procedimiento almacenado.

Sólo faltaba tal y como apuntaba Chris, saber que un procedimiento almacenado se puede llamar igual que cualquier tabla o vista, añadiéndole las condiciones que se necesiten al WHERE.

Un saludo

[[Delphius]]

Debo decir que no hubiera sido posible la escritura del SP sin la ayuda de román cuando presentó esa consulta.

Por ello estoy dispuesto a compartir la mitad del jamón con el maestro román.

Saludos,

[[Chris]]

Empezado por fjcg02

Repasando el hilo completo, Delphius ya daba el 80 % de la solución cuando en su post adjuntaba el código del procedimiento almacenado.

Sólo faltaba tal y como apuntaba Chris, saber que un procedimiento almacenado se puede llamar igual que cualquier tabla o vista, añadiéndole las condiciones que se necesiten al WHERE.

Un saludo

Puede ser que ya se haya encontrado una solución, pero no es la optima realmente. No es muy buena idea que la base de datos funcione de muleta de un programador que no pudo solucionar un problema de la GUI. Agregar un campo más lo único que hará es aumentar la cantidad de datos que deben intercambiarce y para rematar, usando un procedimiento almacendado, la consulta se vuelve más lenta. Con estos dos problemas, todos tus usuarios juntos podrían perder mucho más tiempo del que no quisiste tomarte en moldear una mejor idea.

Obviamente, es decisión de Casimiro en este caso tomar un camino para su solución, pero yo sigo pensando en que es mucho mejor seguir trabajando del lado del código de la GUI en luegar de utilizar la base de datos como solución.

[[Delphius]]

Empezado por Chris

Puede ser que ya se haya encontrado una solución, pero no es la optima realmente. No es muy buena idea que la base de datos funcione de muleta de un programador que no pudo solucionar un problema de la GUI. Agregar un campo más lo único que hará es aumentar la cantidad de datos que deben intercambiarce y para rematar, usando un procedimiento almacendado, la consulta se vuelve más lenta. Con estos dos problemas, todos tus usuarios juntos podrían perder mucho más tiempo del que no quisiste tomarte en moldear una mejor idea.

Obviamente, es decisión de Casimiro en este caso tomar un camino para su solución, pero yo sigo pensando en que es mucho mejor seguir trabajando del lado del código de la GUI en luegar de utilizar la base de datos como solución.

Nunca se ha dicho que sea la más óptima, que sea la mejor, o que fuese la única alternativa.
Es sólo una posibilidad más que se baraja y debo decir que en buena parte tiene su simpleza.

Quizá un SP no se tan rápido que una consulta. Quizá se pierda un poco de velocidad y perfomance cuando se tengan varios registros y sean muchos clientes quienes estén atacando el servidor pero la posibilidad de que esté el SP ayuda a que buena parte del código sea más simple.

Si el motor tiene la capacidad y los datos necesarios para ayudar a facilitar algunas operaciones del lado del cliente es más que una buena posibilidad de evaluarlo. ¿No es acaso una de las reglas que un desarrollador debe siempre considerar?

Si el servidor puede asumir esa tarea y puede darnos los datos pre-masticados que la haga.... para todo lo demás existe mastercard... este... digo el sistema cliente.

No se trata de una chapuza como lo quieres vender, ni que el programador es ineficiente o incompetente por no haber logrado algo por otra vía. Si tanto te preocupa encontrar una solución que no esté vinculada con la base de datos y sea por código yo ya había indicado una vía, que me tomo la molestia de corregir:

Disponer de una estructura, una lista, a modo del campo ficticio "Colorear" y llenar esta lista con los 1 o 0 (o el color, o lo que quieran) para que luego al momento de pintar el DBGrid pueda recuperarse este dato y saber de que color pintarlo.
El punto es que NECESARIAMENTE se debe contar con toda la información de todos los registros para saber de que color pintar. No puede verse y atacar el problema considerando el registro de forma individual, ya que su color está relacionado con su predecesor y es necesario mantener en memoria, de alguna forma, el color asignado para que a efectos de un desplazamiento podamos volver al estado original.

Saludos,

[[Chris]]

[quote=Delphius;386876] ... ... ... [/]
Es obvio que te molestó mi comentario. Sorry, pero es mi opinión y mi filosofía de desarrollo. Por lo que tú digas, no la cambiaré porque no creo estar equivocado.

Tú bien sabes -lo has dicho- que existe una solución sin recurrir a la base de datos, y si esa fuera matar moscas con cañonazos, pues que así sea. Aveces, algunas "tonterías" -desde el punto de vista de la GUI- necesitan cientos de línea y docenas de horas en moldearse."

Empezado por Delphius

Si el motor tiene la capacidad y los datos necesarios para ayudar a facilitar algunas operaciones del lado del cliente es más que una buena posibilidad de evaluarlo. ¿No es acaso una de las reglas que un desarrollador debe siempre considerar?

Si el servidor puede asumir esa tarea y puede darnos los datos pre-masticados que la haga.... para todo lo demás existe mastercard... este... digo el sistema cliente.

Aquí estamos totalmente deacuerdo. Pero esa ley no la debes tomar universalmente. Desde mi filosofía, es adecuado implementar esta regla para la lógica de negocios de la aplicación, no para ayudarte a pintar la GUI. Si tienes problemas para pintar la GUI, pídele ayuda a otro programador, no a la base de datos.

Empezado por Delphius

Quizá un SP no se tan rápido que una consulta. Quizá se pierda un poco de velocidad y perfomance cuando se tengan varios registros y sean muchos clientes quienes estén atacando el servidor pero la posibilidad de que esté el SP ayuda a que buena parte del código sea más simple.

Acaso valdrá la pena que tus usuarios queden colgados por N segundos solo porque un programador prefirió que su código fuera más simple?

Empezado por Delphius

No se trata de una chapuza como lo quieres vender, ni que el programador es ineficiente o incompetente por no haber logrado algo por otra vía. Si tanto te preocupa encontrar una solución que no esté vinculada con la base de datos y sea por código yo ya había indicado una vía...

Cómo tarea es una solución ingeniosa, eso sin duda. Para un sistema en producción, es deficiente. Punto! Mejor sigamos por tu vía, es mucho mejor.

Empezado por Delphius

El punto es que NECESARIAMENTE se debe contar con toda la información de todos los registros para saber de que color pintar. No puede verse y atacar el problema considerando el registro de forma individual, ya que su color está relacionado con su predecesor y es necesario mantener en memoria, de alguna forma, el color asignado para que a efectos de un desplazamiento podamos volver al estado original.

Saludos,

Has terminado muy bien. Sigamos con el hilo, está cada vez más interesante. No lo desvirtuemos.