FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
He probado con Delphi 2010 y el comportamiento es el mismo, dándose esa disfunción en el uso de los filtros.
Por cierto, siento desilusionarte, Al, pero el archivo MidasLib.pas que viene con Delphi 2010 (al menos en el Professional) ocupa apenas 953 bytes, ya que tan solo declara la función externa DllGetDataSnapClassObject para registrarla mediante RegisterMidasLib, pero nada más que rascar. Esta unit hace uso del fichero binario Midas.obj, donde supongo está todo el nucleo de Midas. Respecto a RevertRecord y la aplicación de un filtro, ahí hay un bug gordo que más bien parece estar relacionado con el uso de los filtros en esta clase de Datasets (TClientDataSet). He hecho la prueba de desmenuzar ese código que pones en cuatro partes, y lanzar cada una desde botones diferentes: en la primera se vacía el Dataset y se añaden los dos registros; en la segunda se aplica el filtro; en la tercera se llama a RevertRecord; y por último, en la cuarta se quita el filtro. La sorpresa me la he llevado al cambiar el orden de estas llamadas: 1er paso, creo los dos registros, a continuación selecciono desde el grid el primer registro (ID = 10) y me voy al tercer paso, llamando a RevertRecord; todo ello sin haber aplicado el filtro, de ahí que seleccione el nº 10 desde el grid para asegurarme de que RevertRecord se aplica sobre dicho registro. Bien, en teoría esto debería borrar el registro ID=10 y dejar el ID=11 solamente ¿no?. Pues efectivamente, así sucede. Lo SORPRENDENTE es que si luego aplico el filtro resulta que ... ¡magia potagia! el registro nº 10, que ya estaba eliminado, vuelve a aparecer (lo lógico es que el grid se quedara vacío al aplicar este filtro), y cuando finalmente quito el filtro ahí están los dos, el nº 10 y el nº11. A todo esto quiero añadir que, para hacer ciertas pesquisas, me he servido de una técnica propuesta por Ian Marteens en su libro "La Cara Oculta de Delphi 6", pgs 469 y 470, que consiste en volcar la propiedad Delta (matriz donde se almacenan los datos temporales, caché) de un ClientDataset sobre la propiedad Data (matriz donde se almacenan los datos confirmados) de otro ClientDataset, de forma que podamos ver, tras dicho volcado, qué registros hay presentes en cada momento en la caché del primero. Siguiendo esta técnica, después de cada paso que daba, pulsaba un botón que realizaba dicho volcado y los valores arrojados eran los esperados: es decir, que después de aplicar RevertRecord sobre el registro con ID nº 10, en la caché sólo quedaba el nº 11, por lo que entiendo que el 10 se daba por eliminado correctamente. Lo curioso es que luego, al aplicar el filtro, dicho registro vuelva a aparecer en el Grid, aunque ya no aparece en la Caché, ¿de dónde sale si ya había sido borrado y no estaba ni en la caché ni aparecía en el Grid? Pongo aquí el código que vuelca el Delta del primer ClieentDataSet sobre el Data del segundo, por si quieres hacer pruebas, basta con que enlaces un Grid a este segundo ClientDataSet para ir viendo los registros pendientes de confirmar en el primero:
Saludos
__________________
Guía de Estilo |
#2
|
||||
|
||||
Gracias Andrés.
Es muy interesante lo que describes, y, en efecto, así pasa también en Delphi 7. Ya había echado un vistazo al Delta de la manera que indicas (aunque no lo vi con mucho detalle). Un amigo me dejó ver unos archivos .cpp, que al parecer son los fuentes del archivo .obj que mencionas (creí haber leído que todo el DataSnap estaba reescrito en Delphi). No los he mirado con dedicación porque no dispongo de mucho tiempo ahora (aunado a que le he perdido algo de práctica a C++), pero estoy seguro que dentro de ellos se encuentra la clave de todo este misterio. Sabes, finalmente he decidido crear mi propio método RevertRecord con un parámetro Boolean opcional llamado FilterSafe (10 minutos para definir ese nombre ). Si es True, antes de revertir un registro nuevo, haré un par de llamadas de bajo nivel (DSCursor.PutField y DSCursor.ModifyRecord) para poner en blanco el último campo del registro que no lo esté, pues, como comenté arriba, el problema se evita si modificas el registro nuevo antes de revertirlo. Por cierto, ¿podrías comprobar si eso último es aplicable también a Delphi 2010? Saludos. Al. |
#3
|
|||
|
|||
Cita:
Saludos
__________________
Guía de Estilo |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Connection fallida | el-mono | Firebird e Interbase | 1 | 30-12-2008 22:24:14 |
Migración Fallida | Shadowless | Windows | 2 | 29-10-2008 10:53:12 |
Prueba turbo Delphi Net Fallida | ASAPLTDA | Varios | 0 | 08-05-2007 18:54:39 |
Conexion fallida con FireBird | mvelgar | Conexión con bases de datos | 3 | 05-05-2007 02:59:27 |
Combinación de teclas | Jose_Pérez | API de Windows | 2 | 17-06-2003 11:57:30 |
|