Sincronización en cascada tablas padre-hijo

Buen día,
Toba_2_1_3
Tengo un datos relación, con una tabla padre (Formulario) y una tabla hijo (ML),
cuando se ingresa por primera vez ambas tablas se sincronizan bien;
Al seleccionar del cuadro (Editar) un registro que lleva al formulario de la tabla padre, se pueden actualizar campos que forman parte de la Clave tanto en postgres como en las propiedades de cada Datos Tabla se tiene habilitado para Actualizar en cascada y Permitir modificar claves respectivamente.

El problema es que cuando se trata de sincronizar la tabla Hijo, no encuentra el registro padre que en su orden debe ser actualizado primero; en el Log muestra el movimiento de la tabla hijo, pero no la del padre

SQLSTATE[23503]: Foreign key violation: 7 ERROR: insert or update on table “credito_cuotas_extras” violates foreign key constraint “credito_cuotas_extras_ccx_departamento_fkey” DETAIL: Key (ccx_departamento,ccx_ciudad,ccx_empresa,ccx_sucursal,ccx_seccion,ccx_persona,ccx_tipo_credito,ccx_linea_credito,ccx_credito)=(17,17001,1,1,2,4,1,3,6) is not present in table “credito_encabezado”.

Los dos formularios tienen activado el Evento MODIFICAR IMPLICITO y se encuentran en la misma pantalla, la idea es que con el botón procesar del CI principal, se deben guardar todo en conjunto, primero el padre y luego el hijo.

Como puedo manejar esto ?, me toca manejar la tabla hijo sin que forme parte del datos relación ? La sincronización, no toma en cuenta todas las tablas relacionadas, si se modifica la clave ?

Gracias.

Buena tarde,

Se prueba con toba_referencia con EJEMPLO DE OPERACIONES - ABM_PERSONAS
Se agrega al formulario de Personas el ID, y al ejecutar y tratar de cambiar el valor de la Clave y GUARDAR, rechaza la Persistencia, al tratar de guardar primero las tablas hijo; si quitamos del datos tabla padre el ref_persona_id_seq, la persistencia se ejecuta correctamente, tiene que ver esto con la solución ?? en mi caso, no se modificará el campo del Serial, si no los otros que lo acompañan y que conforman la llave compuesta.

El ML hijo y el Formulario padre, los ubico dentro de una misma pantalla, para facilidad del usuario, en el manejo de CREDITO - CUOTAS

Se parece mucho, al caso del foro http://foro.comunidad.siu.edu.ar/index.php?topic=4362.msg17105
pero ya se probó con los diferentes, ordenes de los componentes, se borraron y se vuelven a crear, pero seguimos con el problema.

Gracias

Favor urge, me dejaron colgado

Hola Jhon,

disculpa la tardanza, estuve arreglando otras cosas y se me quedo colgado tu tema.

Dejame verlo, pareciera ser un bug en ppio… hay que ver si hay forma de solucionarlo.

Saludos

Hola Jhon,

con respecto a este tema, tengo los siguientes inconvenientes:

  • La FK en los hijos se dispara antes de que se llegue a modificar el otro registro.
  • Con una FK que traslade los UPDATES en cascada, el error se produce en el control de concurrencia.
  • Retrasar los triggers en la sincronizacion podria ser una salida para el problema de las FK… sin embargo, aun no se con totalidad si es algo que se pueda llevar adelante asi nomas.
  • Se requiere invertir el orden de sincronizacion con respecto al normal, para poder trasladar los cambios sin necesidad de eliminar todo y volver a crearlo.

Por otro lado, el DT se entera de que se modifico su clave a un nivel muy bajo, osea en el persistidor… para poder trasladar el cambio de la clave, deberia hacerlo mas arriba… incluso a nivel de la relacion.
Trasladar esa logica ahi tiene sus temas, no es algo que vaya a salir cocinado en una semana y probablemente quede para la version 2.4.

Por el momento, me parece que la mejor solucion seria seguir los pasos que mencione en el hilo de Claudio, de dicha forma podes solucionar manualmente el problema y no quedar limitado por nuestros tiempos.

Saludos

OK, Richard

En resúmen, se puede concluir que el tildar PERMITIR MODIFICAR CLAVES en las propiedades del DT, es cuando no es un DR ?
Mil gracias y quedaré pendiente del cambio.

Saludos

Hola Jhon,

por el momento si, es valido siempre y cuando no tengas tablas que dependan de aquella a la que le cambias la clave.

Saludos