![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
#14
|
||||
|
||||
|
No se trata de eliminar el Insert y ver si funciona. Se trata, pienso, en detenerte un momento para examinar qué es lo que haces y lo que debes hacer.
Vamos a suponer que en tu caso tienes un formulario con dos DBEdit. Estos están enlazados a un DataSource que a su vez estará enlazado a un Table. En cada DBEdit tienes asignado el campo al que se conectan. En principio esto es todo lo que debes saber de los DBEdit. Esto es, normalmente no hace falta, ni se recomienda, acceder directamente a los datos del DBEdit, o sea, no usar propiedades como DBEdit.Text. Esto es así porque los controles enlazados a datos son meramente un intermediario entre el usuario y la tabla. Los datos que presentan son reflejo fiel de lo que contenga el registro activo y cualquier modificación que haga el usuario se transfiere automáticamente a la tabla. Todas las operaciones se hacen a través del dataset asociado (el Table en este caso), los objetos TField del dataset, y sus eventos. Cuando abres tu formulario, muy posiblemente tendrás un botón para agregar un nuevo registro con la instrucción: Table.Append; Esto inserta un registro en blanco y deja a tus DBEdit listos para comenzar a escribir sobre ellos sin hacer más nada. Pero observa, debes comenzar con el Append (o Insert, el que gustes), no se trata de una instrucción que se haga después de escribir los datos. Como todos los datos son guardados en un buffer temporal, debes explícitamente indicar que queires grabar los datos con: Table.Post; que tendrías en otro botón. Hasta aquí todo claro, sólo un par de líneas, una en el evento OnClick de cada botón. Viene entonces el asunto de las validaciones. En tu caso debes asegurarte que ninguno de los dos campos esté vacío. Lo que tú estás haciendo ahora, es hacer la validación en el botón que tienes, supongo, para guardar los datos. Pero este es el lugar incorrecto. ¿Por qué? Pues imagina que posteriormente debes manejar la misma tabla desde otro formulario distinto. Ahí tendrás que repetir la validación con lo que ya desperdiciaste código. Además, si en algún momento cambian las reglas de validación, tendrás que hacer las modificaciones pertinentes en todos los puntos donde accedas a esa tabla. El punto es: normalmente la validación es independiente de la forma en que se inserten los registros. No importa si usas dbedits o un dbgrid u otro control similar, la regla debe ser siempre la misma: los campos no pueden estar vacíos. Por ello, enfatizo, no debes basar tus validaciones en los valores de controles específicos. Lo recomendable es centralizar estas validaciones. Hay dos lugares muy propicios para hacer las validaciones. Uno es el evento OnValidate del campo asociado. Para ello debes agregar los objetos TField al dataset dando doble click sobre la componente (el Table) y escogiendo la opción "Select all fields" del menú contextual. O puedes agregar sólo los que requieras ver en tu aplicación. Cuando seleccionas uno de los campos, el inspector de objetos te mostrará las propiedades y eventos específicos para dicho objeto. Ahí encontrarás el evento OnValidate. Ahora bien. Es cuestión de gustos, pero a mi no me acomoda esta forma de validar ya que el evento OnValidate se lanzará cada vez que el usuario intente mover el foco a otro campo, lo cual le impide navegar libremente por el formulario hasta estar satisfecho con lo escrito. En mi opinión esto era más de los tiempos de Clipper y sistemas en MS-DOS. Otro punto donde puedes centralizar las validaciones, es en el evento BeforePost del dataset (el Table). Este evento se generará justo antes de que el registro se guarde en la tabla física, sin importar por qué medios se haga. Puede ser porque explíctamente usaste Table.Post o bien porque estabas en un DBGrid y moviste la selección a otro registro. El evento BeforePost pasa como parámetro el DataSet que se está validando. En este momento ya puedes hacer uso de los valores de los campos: DataSet.FieldByName('campo1').AsString por ejemplo. Si la validación no se cumple, usas abort para cancelar los cambios o raise Exception.Create('mensaje aclarativo'); para indicar al usuario que hubo un problema y además cancelar los cambios. Si observas, la importancia de esto (tanto OnValidate como BeforePost) es que en ningún momento haces referencia a un control en particular y por tanto, la parte medular de tu aplicación, como las validaciones, no dependen de los elementos que uses para la interfaz de usuario, de manera que puedes alterar ésta sin afectar lo importante. Así pues, como ves, no se trata de eliminar el Insert, yo eliminaría todo el código del botón, por drástico que suene. Y una recomendación. Si bien se puede aprender del código de otros, es importante que leas, antes de ponerte a teclear. Un buen lugar para empezar es el libro la Cara oculta de Delphi 4 de Ian Marteens, que podrás bajar gratuitamente de su sitio. Que no te mosquee la versión. Para los conceptos básicos te será igualmente bueno si usas un Delphi posterior. Te aseguro que con una semana que leas la parte dedicada al acceso a datos, serás tú el que esté dando explicaciones a tus compañeros. // Saludos |
|
|
|