¡Hola a todos!
Antes que nada, gracias por sus valiosos comentarios.
Cita:
|
Empezado por amadis
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
...
|
He decidido que el valor predeterminado sea False (ya voté por la primera opción). Abrí la encuesta porque tenía dudas al respecto, pero me convenció el argumento de Román. La intención de este nuevo componente es ampliar las capacidades de un TClientDataSet, no pelearse con éste. La
naturaleza de un conjunto de datos cliente es permitir el manejo de registros en memoria (en
caché), aplicando los cambios a la base de datos hasta llegar el momento "adecuado", reduciendo así el tráfico de red.
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:
|
Empezado por amadis
...este ImmediateUpdates ¿seria un ApplyUpdates y un Refresh juntos?...
|
No, solamente la llamada al método ApplyUpdates.
Código Delphi
[-]
Procedure TMagiaClientDataSet.DoAfterDelete;
Begin
If ImmediateUpdates Then
ApplyUpdates (0);
Inherited DoAfterDelete;
End;
Procedure TMagiaClientDataSet.DoAfterPost;
Begin
If ImmediateUpdates Then
ApplyUpdates (0);
Inherited DoAfterPost;
End;
Cita:
|
Empezado por amadis
...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...
|
Cuando tienes StoreActive en False (el valor predeterminado), el valor de la propiedad Active no se guardará en el archivo .dfm, el archivo donde se almacena todo lo que estableces en tiempo de diseño —generalmente usando el inspector de objetos—. Esto quiere decir que si abres un conjunto de datos en tiempo de diseño para facilitar la labor de delinear un DBGrid, por ejemplo, enseguida puedes compilar el programa y al correrlo no abrirá automáticamente ese conjunto de datos;
la tendencia hoy en día (y lo que señalan los cánones) es que el programa abra los conjuntos de datos por orden explícita, sólo en el momento en que se requieran, para ahorrar recursos y operar con una velocidad óptima.
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.
