TClientDataSet, en Maestro detalle

[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 Noteví]

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.