Campos que se pierden después de un Applyupdates

[AzidRain]

Resulta que tengo un Clientdataset enlazado a con sus componentes de datos y todo. Hago un append al clientdataset y muestro una ventana para capturar los datos, posteriormente con un botón hago el post de los mismos.

En el evento AfterPost del CDS aplico de inmediato el cambio a la base de datos mediante Applyupdates y luego refresco el CDS.

El problema:
El registro si es grabado fisicamente a la base de datos como debe ser pero en la forma todos los campos se borran tan pronto hago el applyupdates de manera que si por ejemplo inmediatamente después de la instrucción applyupdates quiero acceder a un campo del CDS, el campo me aparece vacío. El CDS no lo cierro sino hasta varias líneas después.

No sé si esté haciendo algo mal o me haya faltado alguna propiedad pero ya revise todo y aparentemente está correcto.

A ver si a alguien le ha pasado o si alguien sabe por que sucede esto.

[Caro]

Hola AzidRain, yo trabajo con dbExpress y los ClientDataSet, cuando hago ApplyUpdates sobre el ClientDataSet no me ha dado problemas, lo que si he notado es cuando colocas la propiedad LogChanges a False es como si no obedeciera a ApplyUpdates y no hace nada, no ves cambios en tu BD. Esta propiedad solo lo he utilizado cuando me creo tablas en memoria para que no me grabe todos los cambios que hago sobre cada registro así siempre tengo un solo registro con los ultimos cambios, nose podrías probar de colocar esa propidad a True.

Saluditos

[AzidRain]

Aqui lo raro es que los datos si se van a la base de datos y se guardan, pero como que el clientdataset pierde sincronía o algo porque limpia todos los campos y ya no muestra los del registro que se acaba de insertar y que de hecho se convierte en el actual. Cabe mencionar que hago el refresh correspondiente justo después de aplicar los cambios.

[felipe88]

Cabe mencionar que hago el refresh correspondiente justo después de aplicar los cambios.
Hola Azid, mira que este mismo problema se presenta en un programa que usamos aca en mi oficina (Desarrollado por personas ajenas a la empresa), de un momento a otro este no queria dejar guardar registros, entonces los desarrolladores decidieron añadir unas lineas y un query para solucionar este probrema seguido de un refresh como tu dices... efectivamente hemos tenido que tolerar este molesto efecto visual, si damos click en actualizar los datos nos sale un error "no puede actualizar sin guardar bla, bla, bla..." o si hago click por fuera parece como si los borrara... en fin, desde mi punto de vista y sin ser muy técnico le atribullo al refresh este problema, eso si; no estoy diciendo que sea la unica opción, como he dicho el desarrollo es de otras personas y hasta ahora no han hecho nada al respecto :cool:... espero encuentren la solución, cualquier cosa la comentaré al respecto :)

[AzidRain]

Necio que soy, lo de menos sería cerrar el formulario y tan-tan, si quieren editarlo nuevamente que lo abran con la opción adecuada y punto. El chiste es que los datos que muestra el formulario corresponden a lo que vendria siendo la tabla maestra y a su vez muestra datos de al menos 3 tablas hijas. Esta tabla maestra tiene un campo autoincrementado que la identifica y como es obvio es necesario saber el número que le asignó la BD para a su vez colocarlo en la clave foránea de las tablas hijas. Inicialmente habia pensado en aplicar los cambios con applyupdates y luego acceder al valor de la clave mediante fielbyname de la cdspadre pero ahi fue donde me di cuenta que siempre vaciaba los datos de todo el registro. Lo que hice fue ir directamente a la BD y pedirle el último autoinc y proceder de ahí. Lo que que me ha seguido molestando es el por qué se borran todos los campos justo despues del applyupdates.

[roman]

¿Usas MySQL? Igual no tiene nada que ver, pero tengo idea de haber visto algo relacionado al respecto con los autoinc. Voy a aventurar algo, a ver si no es descabellado:

Cuando haces el Refresh, el CDS debe solicitar nuevamente los datos al servidor (o al provider), pero posiblemente no tenga aún el valor autoinc generado por el servidor; luego entonces, no sabe qué registro pedir.

// Saludos

[AzidRain]

Si Roman, uso MySQL...

Cuando haces el Refresh, el CDS debe solicitar nuevamente los datos al servidor (o al provider), pero posiblemente no tenga aún el valor autoinc generado por el servidor; luego entonces, no sabe qué registro pedir.

Me parece que por ahí podría ser la cuestión, suena lógico, lo voy a probar con otras formas similares que tengo en mi aplicación que igual usan autoincs par a ver que pasa.

[roman]

No he podido reproducir el comportamiento que describes ni con ZEOS ni con MyDAC, ¿qué componentes usas?

// Saludos

[AzidRain]

Uso Zeos....
Ya descubrí que pasa.

Efectivamente es lo que decías Roman. El componente de acceso a datos, un Zquery tiene este SQL:

select * from tabla where campoindice=:campoindice


El parametro :campoindice lo utilizo para acceder algun registro en particular.
Ahora bien cuando deseo insertar uno nuevo ejecuto el query con el parametro en nulo (no devuelve nada obviamente) y hago un Append en el ClientDataset. Lleno todos los campos (excepto el valor clave que es un autoinc) y hago el post + applyupdates. Y aqui todo va bien como ya platiqué, se graba y todo muy bien. Pero...como tu decías y decías bien, para el ClientDataset el sigue teniendo un valor nulo en el parametro por lo que al darle refresh vuelvo a tener el query como al principio de la edición: vacío.

SOLUCION:
Después de hacer applyupdates, obtener el autoinc de MySQL y ahora sí colocarlo en el parámetro que estaba en nulo al principio y hacer el refresh. Voilá...funciona perfecto.

Gracias Román.