FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
Ver Resultados de Encuesta: ¿Cuál valor predeterminado (default) prefieres para la propiedad ImmediateUpdates? | |||
False (se usaría más así) | 5 | 71,43% | |
True (se usaría más así) | 2 | 28,57% | |
Votantes: 7. Tú no puedes votar en esta encuesta |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
TClientDataSet.ImmediateUpdates
¡Hola a todos!
¿A poco no sería fabuloso que el componente TClientDataSet tuviese una propiedad llamada ImmediateUpdates, para indicar cuándo queremos que se apliquen los cambios (ApplyUpdates) a la base de datos de manera inmediata?. Muchos programadores Delphi recurrimos al uso de los eventos AfterPost y AfterDelete del conjunto de datos cliente, para llamar desde ahí al método ApplyUpdates cuando queremos que la base de datos se actualice immediatamente después de guardar o eliminar un registro. Pero cuando tenemos un módulo de datos con treinta o cuarenta componentes TClientDataSet la cosa se torna fea (demasiado trabajo repetitivo por falta de una propiedad como la mencionada). Hace días que vengo utilizando mi propio componente derivado: TMagiaClientDataSet, al cual le voy agregando características según descubro las carencias de su clase padre (TClientDataSet). Le definí una propiedad Provider que permite enlazarlo con un proveedor que se encuentre en otro módulo de datos de la misma aplicación; también una propiedad StoreActive que evita (si se quiere) que se guarde la propiedad Active en el archivo .dfm. Ahora he decidido definirle una nueva propiedad llamada ImmediateUpdates. La idea es sencilla: que si esta propiedad tiene un valor de True, se llame de manera automática al método ApplyUpdates después de cada operación de guardado o eliminación de registro. Eso ayudaría a reducir código y trabajo de programación operativa (el burocrático uso de los eventos AfterPost y AfterDelete de cada conjunto de datos). La principal razón de este mensaje es preguntar a los conocedores del tema, cuál valor debería ser el predeterminado (default) para esta nueva propiedad, ¿True o False?. En términos prácticos, ¿cuál se estaría usando más por los programadores Delphi que emplearan este nuevo componente?, ¿ImmediateUpdates = False?, o ¿ImmediateUpdates = True?, ¿por qué? Muchas gracias por participar en la encuesta y exponer sus opiniones sobre este tema. Un abrazo aplicado. Al González. Última edición por Al González fecha: 12-04-2006 a las 07:05:04. |
#2
|
||||
|
||||
He votado True porque en todos los programas en los que he participado en su desarrollo siempre aplicamos la "actualización" inmediatamente después de que se produce una edición/inserción o eliminación.
Además, opino que, salvo que permitamos el trabajo en modo "briefcase", es peligroso posponer mucho la actualización hacia la base de datos debido a los problemas que puedan ocurrir (corte de corriente, cuelgue del sistema operativo, etc.), en cuyo caso se perderían todas las modificaciones hechas al estar sólo en la "cache" (y hablo por experiencia, imaginad como explicarle al cliente que las últimas modificaciones hechas se perdieron porque "se fué la luz!"). En fín, a ver que opináis los demás... Saludos! P.D: Sólo decir que me parece muy buena idea lo de adaptar el TClientDataSet, nunca se me ocurrió "personalizarlo" sino que más bien me las rebuscaba para intentar que todo funcionara correctamente. |
#3
|
||||
|
||||
Pues yo he votado false. No es que considere mala idea hacer esto en automático pero sí pienso que hay que andarse con tiento. Difícilmente consideraría esto como una carencia del TClientDataSet original. Me parece que el uso de ApplyUpdates es parte clave del diseño, encaminado a la disminución del tráfico en la red, no sólo un paso extra para hacernos programar más. Quizá el uso de ApplyUpdates es más algo a lo que haya que acostumbrarse como parte de una filosofía de programación, más una regla que una excepción y por ello false por defecto que no true.
Lo que me parece genial es el la propiedad StoreActive. ¡Cuántos dolores de cabeza no da el dejar esta propiedad activa durante el diseño! Creo que ninguna componente derivada de DataSet debió dejar siquiera la opción de poder almacenar esto en el dfm. // Saludos |
#4
|
||||
|
||||
false, por los motivos que explica roman.
Lo de storeactive: genial, se evitan muchos quebraderos de cabeza. Bueno, coincido por completo con roman |
#5
|
|||
|
|||
True
VOTO POR EL TRUE.
Ya que hace unos dias publique un hilo CLIENTDATASET vs TTABLE Y eso creo que solucionaria el problema que he estado teniendo... de reflejar los cambios inmediatamente. El que no lo quiere que siga con el ClientDataSet tradicional Ahora una cuestion este InmediateUpdates ¿seria un ApplyUpdate y un refresh juntos? Ya que yo he estado usando esa combinacion en el AfterPost y AfterDelete y otros after y con el crecimiento de la tabla se torna muy lento el refresh al punto que es inaguantable. En cuanto al StoreActive desconozco su utilidad y buscando en la ayuda de delphi no entendí mucho mas de lo que desconozco así que les agradeceria una ayuda sobre eso. |
#6
|
||||
|
||||
ImmediateUpdates y StoreActive
¡Hola a todos!
Antes que nada, gracias por sus valiosos comentarios. Cita:
En mi proyecto actual tengo un módulo de datos con varias decenas de este nuevo componente y, por razones particulares de esta aplicación, pondré la propiedad ImmediateUpdates de todos ellos en True (es un trabajo menor, comparado con el de utilizar los eventos AfterDelete y AfterPost de cada componente). Es muy probable que yo mismo y otros programadores hagan esto en otros proyectos, ya que muchos desarrolladores Delphi preferimos que los cambios se envíen a la base de datos lo más pronto posible (por todas las ventajas de lectura, validación, etc., que ya conocemos). Sin embargo, esta manera de usar la propiedad ImmediateUpdates, aunque puede llegar a ser una "regla cultural", sigue siendo una "excepción natural" (excepción a la naturaleza de un conjunto de datos en memoria). En todo caso, para facilitar aún más el trabajo, quizá después cree una clase de módulo de datos que tenga una propiedad DefaultDataSetSettings —o un componente por el estilo—, donde el programador pueda establecer de forma centralizada cuáles son sus preferencias predeterminadas para todos conjuntos de datos que se coloquen dentro del módulo. Cita:
Cita:
Así mismo, cuando vuelvas a abrir el proyecto en Delphi, los módulos de datos no demorarán en cargarse, ya que no tratarán de abrir los conjuntos de datos que hayas dejado con las propiedades Active en True y StoreActive en False. En pocas palabras, StoreActive concilia la tendencia de conjuntos de datos cerrados con la necesidad de abrirlos para diseñar. Un abrazo activo. Al González. Última edición por Al González fecha: 13-04-2006 a las 21:54:48. |
Herramientas | Buscar en Tema |
Desplegado | |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
TClientDataset Uso | samantha jones | Varios | 1 | 09-03-2005 21:22:20 |
TClientDataSet | carlomagno | Firebird e Interbase | 0 | 09-09-2004 11:29:23 |
TClientDataSet xml | carlomagno | Firebird e Interbase | 0 | 03-09-2004 11:32:25 |
TClientDataSet y el SO | tgsistemas | OOP | 4 | 02-08-2004 15:01:20 |
TClientDataSet | saul_montalvo | Conexión con bases de datos | 1 | 08-09-2003 04:38:10 |
|