Cita:
|
Empezado por ArdiIIa
aunque tal como comenta Lepe, creo que lo mejor es usar unas reglas de validación en cada control,
|
¡Eh! ¡ a mí no me metas en líos ehhh!
que yo solo he respondido a la pregunta concreta
.
Ya en serio, estamos en el foro Varios y se habla de Bases de datos, pero no sabemos cual, tampoco sabemos mucho acerca del programa en cuestión, si son muchas las validaciones o es
una sola, si estamos en Cliente/Servidor o no.... Así que solo respondí a la pregunta.
Normalmente este tipo de validaciones es mejor hacerlo en la Base de datos:
- Que un campo se necesita, poner NOT NULL en su definición, que sea el motor de Bases de datos quien haga saltar el error, y después manipulamos el mensaje a mostrar al usuario (para traducirlo a español).
- Que un valor no debe repetirse, añadir un índice único sobre ese campo, ya no tendremos que hacer búsquedas para saber si el nuevo dato se repite o no.
- Que debe restringirse el rango de datos, (porcentajes entre 1-100, que no permita números negativos), usar los Checks (si se puede)
- etc.
Ahora que recuerdo, con los eventos OnExit y OnEnter, existe un problemilla: el usuario puede modificar un campo pero no salir de ese DBEdit (porque usemos un SpeedButton para guardar los cambios; un control que no adquiere el foco y por tanto, al pulsarlo, no hará saltar el OnExit del DBEdit), así que el mensaje de error que programemos nunca se verá, y lo más grabe ¡¡ a saber qué guarda en la Base de Datos!! (incoherencias, inconsistencia de datos...).
Es cierto que quizás sean conceptos nuevos, o incluso más engorroso de implementar por primera vez, pero sin duda, más fiable que el método "rápido y poco limpio" de usar OnExit y OnEnter.
Como siempre, dependerá de qué y cómo quiere hacerlo.
Saludos