Estimados amigos.
Estoy haciendo un abm que usa un Datos Relación (DR) compuesto por dos Datos Tabla (DT). Es el caso más simple de todos un padre y una tabla de hijos. La relación es de 1:n.
Cargo los DT con los formularios correspondientes, pero al intentar sincronizar el DR, arroja un error de sincronización. Parece que el Toba intenta sincronizar antes la tabla hija, por lo que se le presenta la inconsistencia de no tener padre.
Estuve buscando entre los mensajes de otros colegas, y encontré casos similares, lo que no encontré es la solución. No se si por ahí la postearon y no acierto a encontrar el hilo pertinente.
He probado cambiando el orden de las tablas en el DR (manteniendo la relación padre hijo)
te hago una consulta, en la pestaña donde definis que tablas integran la relacion… le colocaste los limites maximos y minimos a la tabla padre?.
Me suena a que cuando esta agregando los datos para las tablas hijas, no encuentra con que cursor en el padre asociar esos datos.
Por otro lado, podrias adjuntarme el error que te tira asi vemos que puede estar pasando?.
Como es el mismo tema, y fue el que plantee ya hace algun tiempo, y el ticket se encuentra colgado, lo podemos seguir por acá.
A lo que pregunta Richard, manejamos MINIMOS 0 Y MAXIMO 1 para la tabla padre, y para las tablas hijos los campos se dejan vacios; se cambiaron el orden, se borroó todo el CI y se volvió a crear y el error persiste.
Pienso que tiene que ser un Bug, ya que le voltiamos mucho y al no encontrar solución con todas las combinaciones posibles, nos tocó hacer a pie todo el proceso de sincronización, es decir separando las tablas hijo de la tabla padre.
No es el mismo caso, Claudio en ningun momento menciono que este modificando las claves del padre.
Con respecto a tu tema, aun estoy viendo como hacer para que el datos_tabla tome consciencia en un nivel superior de la modificacion de las claves y lo pueda transmitir hacia el hijo.
No te respondi porque es un cambio profundo, que tiene muchas aristas… las cuales aun estoy evaluando, por tu urgencia con el tema te recomendaria que lo manejes mediante codigo.
La forma seria:
Detectar el cambio de claves
Borrar los elementos en la tabla hija
Modificar el padre
Dar de alta nuevamente los elementos en la tabla hija
Con esos pasos tenes que poder lograr el objetivo, la diferencia es que los tenes que codificar vos en lugar de hacerlo internamente el objeto de persistencia.
Hola Richard.
Lamentablemente, no anduvo. Probé poniéndole los límites a al tabla padre. Hice las combinaciones de min y max 0-1 y 1-1, pero sigue el mismo error.
Es como si quisiera actualizar primero la tabla hija.
Avisen si se soluciona, si no vamos a tener que sincronizar los datos tabla por separado, y en el caso de claves autonuméricas, habrá que hacer la consulta de inserción porque será necesario recuperar el número que le adjudica la secuencia para rellenar el campo relacionado en los registros de la tabla hija.
Estimado Richard, la patada que tengo en caja de ahorro va cobrando intereses, espero que me condones la deuda.
Te comento respecto a este problema.
Empecé a hilar más finito y veo - me avivé - que el error no estaba a nivel sql, sino a nivel toba.
Cuando el programa intentaba insertar con el método ‘nueva_fila’ del DT hijo, generaba el error de que no tiene padre.
Me pregunté ¿por qué, si yo genero el ‘nueva fila’ del DT padre ANTES de cargar la tabla hija? Entonces pensé que tal vez, aunque la tabla padre tiene un solo registro, al ser nuevo el cursor no se posiciona en dicha fila y la tabla hija se siente huérfana.
Lo unico que hice fue agregar la sentencia
$this->rel()->tabla('socios')->set_cursor(0)
a continuación del nueva_fila de la tabla padre, y a partir de allí todo fue como el Dios de la 'Tercera Forma Normal ’ dijo al principio de la era de las bases de datos relacionales.
Creo que Jorozco tenia un problema similar, a lo mejor viene por el mismo lado.
Nuevamente me disculpo porque mi burrez te robó tiempo, esfuerzo y sembró confusión.
(me queda el asunto de los popups anidados en el toba 2.2.0, estoy probando ambas versiones)
Jajajajaja… si algun dia paso por Corrientes arreglamos
Entonces pensé que tal vez, aunque la tabla padre tiene un solo registro, al ser nuevo el cursor no se posiciona en dicha fila y la tabla hija se siente huérfana.
Lo unico que hice fue agregar la sentencia
$this->rel()->tabla('socios')->set_cursor(0)
a continuación del nueva_fila de la tabla padre, y a partir de allí todo fue como el Dios de la 'Tercera Forma Normal ’ dijo al principio de la era de las bases de datos relacionales.
Por esto te decia lo de setear los limites minimos y maximos en 1 para la tabla padre, eso hace que el cursor se setee automaticamente en la misma cuando tiene el registro en memoria.
Vos me decias que eso no te estaba funcionando y por eso mi insistencia para ver si podia replicar aca el problema.
Creo que Jorozco tenia un problema similar, a lo mejor viene por el mismo lado.
Lo de Jhon viene por otro lado, estando la relacion cargada.. él modifica las claves de la tabla padre, el tema es que la relacion interna no cambia... pero si lo hacen los datos de la clave.
El problema alli, es que para trasladar dicho cambio se requiere desactivar momentaneamente los triggers y quizas el control de concurrencia, si es que la FK esta creada con un ON UPDATE CASCADE.
Eso lo hace mas complejo de resolver, porque el nivel donde se toma conocimiento del cambio esta bastante cercano a la bd.
