TClientDataSet, en Maestro detalle

[JorgeBec]

Ok, planteo mi problemática o duda. Estoy usando dos ClientDataSet para un modulo de ordenes de compra, Uso el ClientDataSet para mantener en memoria los datos y no se actualicen al momento, sino hasta que oprima un boton...Pero el problema viene como controlar el Id del maestro, para que este sea grabado en el detalle???, alguien me podria decir como soluciona esto de la manera mas practica y correcta????


agradecere sus respuestas...

PD estoy usando los componentes de Zeos y una Base de datos PostGreSql...

[JorgeBec]

A la fecha no he recibido respuesta, es dificil la solucion???, me preocupa por que es algo muy comun, o estoy atacando mal el problema...

como siempres agradecere sus respuestas...

[guillotmarc]

Hola

Personalmente utilizo el evento AfterInsert de clientdataset detalle. Es una simple linea de codigo :

procedure Form1.CdsDetalleAfterInsert(Dataset: TDataset);
begin
  CdsDetalle.FieldValues['IdFactura'] := cdsMaestro.FieldValues['IdFactura'];
end;

Saludos.

[JorgeBec]

Interesante tu respuesta guillotmarc, pero lo he estado intentando y siempre el id del maestro es 0, No entiendo porque, explico las caracteristica del ambiente en que trabajo.l

Base de datos : PostGreSql
Delphi 4

y los id son autoincrementables (bueno postgresql lo maneja como secuencias).

ahora el comportamiento es el que sigue, si pongo la linea que me dijiste en el metodo AfterInsert del CDS me da 0 el id, ok, pense a lo mejor internamente no lleva el id al CDS. Y me dije pues lo llevo al qry directamente y oh sorpresa! al debugear el id me lo da en 0, es el unico campo que me da un valor erroneo, pero que creen??? a la hora de irme a la pgadmin ya tiene el id incrementado y obviamente graba el registro del maestro pero el del detalle no por la integridad referencial, PORQUE PASA ESTO???

agradecere sus respuestas...

[maro]

Hola,

No he trabajado nunca con el motor de base de datos que comentas, pero creo conocer el problema.

Suponiendo que el id es autogenerado por la base de datos, el problema es bien sencillo. basicamente, el clientdataset trabaja con una copia del registro original cargada en memoria y almacenando los cambios que se efectuan sobre este, cuando ejecutamos el applyupdate, el clientdataset pasa las modificaciones a la base de datos. Si al recibir estas modificaciones la base de datos altera estos valores, estos no llegan al Clientdataset, salvo que efectuemos un refresco del registro activo.

No obstante, si este es tu problema, existen soluciones más adecuadas para él.
Espero que te ayude.
Saludos

[guillotmarc]

Hola.

Como comenta Maro, este problema es debido a que el valor del campo ID lo proporciona el Servidor, y el ClientDataset no lo conoce.

Es más cuando vas introduciendo los detalles, es posible que aún no hayas grabado la cabecera, por lo que no hay forma de saber cual será su valor de clave primaria (ya que solo lo asigna automaticamente el servidor al grabar).

Imagino que las secuencias de PostGree deben ser parecidas a los generadores de Firebird, que es la base de datos que utlizo habitualmente.

En Firebird, no habilito ningún trigger para que el servidor asigne la clave primaria en función del generador (secuencia). En lugar de ello, al crear un registro en el clientdataset (en el evento AfterInsert) hago una consulta para averiguar el nuevo valor del generador, y se lo asigno a la clave primaria. De esta forma no tengo que esperar a grabar el registro para tener el valor dela clave, y cuando creo los detalles ya conozco el valor de la clave de relación.

Seguramente podrás hacer algo parecido en PostGree.

Saludos.

[Gabriel]

Hola
Jo empleo dos generadores, bueno tambien puede ser un generador y una tabla de contadores.
Al iniciar una factura busco el numero que me va a dar el contador y le aumento ya en 1 para si alguien creara otra factura el numero ya esta incrementado.
bueno ja tengo el numero, si cancelo factura pues nada , adios y muy buenas porque el numero que tengo no es realmente el numero que ira a la factura , es un numero que tengo guardado para la integridad referencial.

Bueno sigo haciendo la factura y en los detalles voy clavando en numero escondido.
Al final al aceptar la factura busco en el contador el numero real de la factura y lo pongo, pero realmente solo es el numero de la factura, el numero de referencia de los detalles con la factura es el numero escondido.

El unico problema es que tienes que crear un indice mas, pero a mi lleva años funcinandome.

Un Saludote

[Gabriel]

Perdon ha habido un error

Donde pone

Al iniciar una factura busco el numero que me va a dar el contador y le aumento ya en 1

Realmente el primer numero lo busco en el Generador , no en el Contador.

En el contador busco al final el numero real que llevara la factura.
Incluso si quiero puedo cambiar ese numero de la factura, porque realmente la integridad referencial me la mantiene el numero del Generador, que tengo escondido


Otra ves
Un Saludo

[maro]

Hola Gabriel,

Tu estructura lógica la veo muy buena ( yo utilizo casí el mismo procedimiento), tan solo ( creo ) le matizaría un pequeño detalle, casi sin importancia.

Lo de utilizar un indice interno para el control de los cambios sobre un registro lo voy muy acertado, si lo estás convinando con un generador para obtener el siguiente id mejor.
El pego ocurre, que estás dando por hecho que cuando el usuario inicia una factura la va a confirmar, sino la confirma estás disparando una serie de eventos en el servidor que no son necesarios y por lo tanto ( desde mi punto de vista ) estás ocupando el servidor en tareas que se pueden realizar en el momento que se confirma la operación, además puedes tener problemas de concurrencia, en grupos de trabajo.
Parece un detalle sin importancia, pero en aplicaciones vía Internet y con un número considerable de usuarios, cada consulta que ejecutas sobre un servidor de base de datos vale su precio en Oro.

Espero que no te moleste este comentario.
Saludos.

[daniel73]

Bueno, he leido y releido estos comentarios y me dan ideas, la idea es la siguiente, veamos a ver si funciona, la escribiré de todas formas:

Se necesita que el ClientDataset Maestro aplique las actualizaciones (aqui ya se genera un error que dice que no se encuntra el registros para la tabla maestra), pero este se genera es por el ClientDataset Detalle y tarea que efectua el Provider. Por otro lado el ClientDataset Maestro necesita llevar las actualizaciones al servidor (o a la base de datos) y una vez entra el registro, se refresca el registro y se lleva al ClientDataset Maestro con el Id conocido. Simultaneamente en el provider hay un evento OnUpdateData y OnUpdateError, en el cual si mal no leí en la ayuda de Delphi, uno puede escoger que actualiza del Delta a la base de datos, de tal manera que cuando pase por el Delta del Detalle, lo rechace (guarde en memoria, aqui va mi idea, etc) y cuano ya el ClientDataset Maestro tenga el Id conocido, se pueda grabar el detalle.

Viendo lo que acabo de escribir, existen riesgos de perder los datos del detalle (creo) no se si alguien me capta la idea, estoy cansado, con tenerla escrita la miraré mañana y espero alguien desenrede esta idea.

Gracias a todos,

Att.

DANIEL

[santi33a]

Empezado por maro

Hola Gabriel,

Tu estructura lógica la veo muy buena ( yo utilizo casí el mismo procedimiento), tan solo ( creo ) le matizaría un pequeño detalle, casi sin importancia.

Lo de utilizar un indice interno para el control de los cambios sobre un registro lo voy muy acertado, si lo estás convinando con un generador para obtener el siguiente id mejor.
El pego ocurre, que estás dando por hecho que cuando el usuario inicia una factura la va a confirmar, sino la confirma estás disparando una serie de eventos en el servidor que no son necesarios y por lo tanto ( desde mi punto de vista ) estás ocupando el servidor en tareas que se pueden realizar en el momento que se confirma la operación, además puedes tener problemas de concurrencia, en grupos de trabajo.
Parece un detalle sin importancia, pero en aplicaciones vía Internet y con un número considerable de usuarios, cada consulta que ejecutas sobre un servidor de base de datos vale su precio en Oro.

Espero que no te moleste este comentario.
Saludos.

Tengo una situación muy similar por lo que te agradecería alguna sugerencia

Santiago

[adr_001]

al parecer este tema ya tiene mas de un año pero si te sirve de algo en lo que estas haciendo lo unico que necesitas es tener una bandera y con ella controlar el incrementable de la tabla maestra+1 y con esto te dara el numero que necesitas para la tabla detalle esa la controlas tu manualmente espero te sirva de algo llevo haciendo desde hace un buen tiempo los programas y es la mejor forma que encontre para eso le intente algunas veces con algunos componentes y no me molestaria si alguien tambien me dijera que existiera una forma mas simple de hacer esto
saludos
y vamos a la feria de San Marcos en Mexico

[egarc]

Buenas, mi solución a esto es no asocioar o relacionar las tablas, sino que en mis programas le pongo el ID autonumérico, luego, despues que hago el commit y cierro la tabla, localizo mi registro de nuevo, por medio de una sentencia sql que me devuelve la última transaccion del usuario que esta usando el programa, luego que localizo mi registro y ya sé qué número le puso el manejador de bases de datos, comienzo a grabar el detalle, con el número de antes dicho.

si no te funciona, me avisas, que son infinitas soluciones y mas cuando usamos delphi

[[Al González]]

¡Hola a todos!

Sé que este tema inició hace mucho tiempo, pero creo que puede servir de algo comentar la solución que empleo en mis proyectos.

Es algo muy simple. Consiste en hacer, dentro del evento OnNewRecord o AfterInsert del conjunto de datos maestro, una consulta a la base de datos preguntando por el siguiente valor de mi generador (secuencia) de IDs. Y ahí mismo, en dicho evento OnNewRecord / AfterInsert, asigno al campo ID del conjunto de datos maestro el valor obtenido.

Es decir, le doy el valor al campo llave dentro de la aplicación cliente desde que inicia la captura del registro. Así, cuando comience la captura de filas detalle, éstas tomarán el valor ya asignado al campo ID maestro (por la relación maestro-detalle que tengan establecida los conjuntos de datos).

A esto le llamo tener una llave maciza de donde asirnos desde el principio.

Seguramente alguien habituado a la vieja y mala costumbre de usar campos visibles como llaves primarias exclamará: «Oye, pero eso es ocupar un número de la serie consecutiva para un registro que tal vez el usuario no guarde; ¡si cancela podría quedar un hueco en la numeración si otro usuario captura y guarda un registro maestro en ese mismo momento!». O bien argumentará que las llaves de dos registros consecutivos podrían no corresponder al orden en el que se guardaron dichos registros.

Señores: ocupar un ID de oque (jejeje, mi madre suele decir "dioquis" y hasta ahora sé cómo se escribe realmente) o que resulte guardado en desorden respecto a otros IDs de la tabla no debe tener importancia alguna. La llave primaria debe consistir en un campo único, pero no tiene por qué ser un valor visible o representativo para el usuario (de hecho ahorra muchos problemas si evitamos esto último).

Incluso, en mis bases de datos acostumbro tener un solo generador (secuencia) para las llaves primarias de TODAS las tablas. Esto hace que cada registro sea verdaderamente único a nivel global de la base de datos (lo cual es meramente un extra, digamos por aquello de las uniones verticales —Union—). No veo por qué andar creando un generador / secuencia por tabla a menos que estén pensadas para contener 2147483647 registros, algo que no aplica a los sistemas comunes de la vida real.

Así manejo el campo ID de las tablas. Y cuando requiero una numeración consecutiva, recurro a un campo adicional llamado, por ejemplo, Numero, ese sí, visible y representativo para el usuario. El campo ID es la agarradera que identifica a cada registro, o sea, es la llave primaria; el campo Numero es otro boleto y no debe usarse como llave de ningún tipo.

Este enlace a otro hilo similar puede ser de utilidad: http://www.clubdelphi.com/foros/showthread.php?t=32546

Un abrazo macizo.

Al González.

[Casimiro Notevi]

Tan sólo comentar que estoy totalmente de acuerdo con el planteamiento expuesto por Al González. Yo lo uso de esa forma también.

[[Al González]]

Empezado por Casimiro Notevi

Tan sólo comentar que estoy totalmente de acuerdo con el planteamiento expuesto por Al González. Yo lo uso de esa forma también.

Casi, ¿me das otra vez tu número de cuenta bancaria?

jajajajaja , es broma. Me alegra saber que lo haces de igual manera.

Un abrazo interbancario.

Al González.

[Casimiro Notevi]

Empezado por Al González

Casi, ¿me das otra vez tu número de cuenta bancaria?
jajajajaja , es broma. Me alegra saber que lo haces de igual manera.
Un abrazo interbancario.
Al González.

Vaya!!!, te la envié, debe haberse perdido en uno de esos mensajes que han desaparecido del servidor, te lo vuelvo a enviar por correo privado



p.d.: no, no uso ese delphi

[Gong]

Yo uso el ejemplo de este artículo. Da alguno problemillas (internalcals, etc) pero me va muy bien.

http://dn.codegear.com/article/20847