FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
AutoCancelDetails, ¿por default True?
¡Hola a todos!
Cuando tenemos una relación maestro-detalle entre dos conjuntos de datos, al llamar al método Cancel o Delete de la tabla maestra, una de las primeras cosas que sucede es que la tabla detalle intenta guardar su registro actual en caso de que éste se encuentre en modo de edición o inserción y la propiedad Modified esté en True. He revisado el código de la VCL, descubriendo la causa de ello. Tiene que ver con el evento interno deCheckBrowseMode lanzado por los métodos mencionados, y tal comportamiento puede ser hasta cierto punto respetable y útil. No obstante, en muchas ocasiones me ha resultado inconveniente que suceda eso. Al grado de que he llegado a escribir código como este:
Parece algo simple, pero una regla que he aprendido de la programación es que por cada sentencia escrita aumenta la probabilidad de los problemas. ¿Qué pasa si, en lugar de uno solo, son tres los conjuntos de datos detalle de nuestra tabla maestra? Tendríamos que escribir algo como esto:
¿Y si fuera una relación maestro-detalle triple Tabla1-Tabla2-Tabla3? Tendríamos que asegurarnos de establecer el correcto orden de cancelaciones:
No vayamos a poner por error primero Tabla2 y luego Tabla3 porque nos aguada la sopa. Todo esto me ha llevado a agregar una nueva propiedad Boolean a mi componente derivado de TClientDataSet, la cual he llamado AutoCancelDetails (se aceptan sugerencias de nombres alternativos). La idea es que si esta propiedad tiene un valor de True, baste una sola sentencia para cancelar el modo de edición en todos los conjuntos de datos relacionados.
De igual forma, una sentencia como se aseguraría de cancelar el modo de edición de todas las tablas detalle. La pregunta de los 64 GB: ¿Debe tener esta nueva propiedad un valor predeterminado de True? Esto significaría que el componente predeterminadamente tendría cierto y muy específico comportamiento que diferiría del nativo, lo cual podría darle más peso a que el valor predeterminado sea False. ¿Pero acaso no son muy pocas las situaciones donde desearíamos que un Cancel o un Delete sobre una tabla maestra se asegure de guardar un posible registro en edición de sus conjuntos de datos detalles? ¿Ustedes qué opinan? ¿Aprueban esta declaración?
Gracias por sus opiniones. Al González. Última edición por Al González fecha: 21-11-2007 a las 21:43:40. |
#2
|
|||
|
|||
Cita:
El problema existe ya lo has comentado (por alguna razón que no acabo de digerir) ¿crees que sea recomendable tener la opción de asignarle False? Bueno mas que una respuesta te he puesto otra pregunta, perdón pero yo como caral, soy un novato en esto que expones..... Salud OS
__________________
"La forma de empezar es dejar de hablar y empezar a hacerlo." - Walt Disney |
#3
|
||||
|
||||
Pues yo la apruebo, definitivamente es algo en lo que estoy de acuerdo contigo, esta propiedad debe tener como valor predeterminado True...
Aunque aún asi no lo colocaria de caracter obligatoria, pueden haber casos en los que al usuario final le sirva tener esa caracteristica en False (En este momento no me imagino alguno, pero el caso debe existir).
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!" http://www.purodelphi.com/ http://www.nosolodelphi.com/ |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
alter table y default | jonmendi | SQL | 1 | 10-11-2005 17:32:05 |
'default Character Set Iso8859_1' | Io | Firebird e Interbase | 3 | 07-09-2005 17:46:19 |
DBCheckBox Default | Kreyser | Conexión con bases de datos | 1 | 21-08-2004 17:35:55 |
There is no default printer currently selected | gynch | Impresión | 2 | 31-03-2004 19:01:45 |
asignar valores por default | NickName | Firebird e Interbase | 3 | 14-09-2003 12:01:43 |
|