[SOLUCIONADO] Guardar genera un Insert en lugar de Update

Buen día.

Estoy empezando a trabajar con el SIU Toba y quiero desarrollar un abm, estoy siguiendo lo más posible lo que está en los ejemplos del proyecto de referencias del Toba, las principales diferencias son que la fuente de datos del dominio es una base Oracle y la versión del Toba que por ahora tiene que ser la 2.6 por que estoy sobre un repositorio de código heredado. Todo funciona bien hasta que intento guardar editando un registro del ABM, pero en lugar de hacer un update intenta hacer un insert.

Alguna idea de que podría estar haciendo mal?

Cualquier información adicional que requieran me avisan.

Desde ya, muchas gracias.

Hola Juan,

primeramente, Toba no tiene soporte oficial (clase toba_db_xx) para Oracle… pero si ya lo tenes andando no creo que haya mucho drama con seguir usando ese.
Segundo, deberias ir pensando en actualizar lo antes posible la version de Toba… dado que estas trabajando seguramente con PHP 5.4/5.6 en el mejor de los casos… y hace rato que dichas versiones no tienen soporte.

Por otra parte, que intente hacer un insert en lugar de un update… depende de como este creada la operación, si me haces una captura del arbol de la misma por ahi puedo orientarte mejor.

Saludos

Buen Día.

Muchísimas gracias por la atención.

Tenemos planeado actualizar una vez estabilicemos los proyectos actuales, es que retomamos un desarrollo que tenían de hace tiempo en otra empresa con las cosas en este estado y tenemos algunos deadlines que cumplir, así que no queremos introducir mas ruido por el momento, pero si, en cuanto tengamos el tiempo y algo mas de experiencia con el framework lo vamos a actualizar.

Adjunto el árbol de la operación como la tengo armada hasta el momento, si necesita cualquier otra cosa me avisa. Como le comentaba, la conexión con la base Oracle parece estar funcionando bien, puedo recuperar los distintos listados y abrir la pantalla de edición con los datos y combos cargados correctamente, es solo al momento de hacer el guardar que falla. Para el caso, el insertar que genera también esta correctamente armado, es solo que debería ser un update.

Desde muchas gracias.

Saludos Cordiales.
Juan.


ArbolOperacion.png

ArbolOperacion.png

Hola Juan,

te hago un pedido, podrias subirme el codigo de los 3 Ci’s de la operacion?, quisiera ver mejor como es que se van relacionando con el DR.

En particular, creo que en el metodo evt__form_expediente__modificacion() estas usando $dt->set($datos) para pasar lo que te llega del formulario al DT… lo cual genera una nueva fila si el DT en cuestion no se halla cargado con datos previamente. Por eso quiero ver como interactuan los cuadros con el DR.

Saludos

Buenas Tardes.

Adjunto el código solicitado, me pidieron que ofusque las queries, disculpe por la molestia, espero que esto no sea un problema.

Le comento, estoy usando el mismo archivo php “ci_navegacion” tanto para el Ci ABM Expedientes como para el Ci bandejas, ahora que me dice es posible que esto este causando algunos problemas, no estoy seguro si el problema del update también pero. El Ci editor tiene su propio php “ci_edicion”.

La carga del DT la estoy haciendo al seleccionar una de las filas de alguno de los listados en el archivo ci_navegacion linea 72.

De nuevo, muchas gracias por su tiempo.

Saludos Cordiales.
Juan.


ci_navegacion.txt (4.12 KB)

ci_edicion.txt (3.08 KB)

Hola Juan,

No hay problema, la idea es ver la logica del codigo… no son necesarias las SQLs, ademas la interaccion del problema se hace via objetos de persistencia.

Le comento, estoy usando el mismo archivo php "ci_navegacion" tanto para el Ci ABM Expedientes como para el Ci bandejas, ahora que me dice es posible que esto este causando algunos problemas, no estoy seguro si el problema del update también pero. El Ci editor tiene su propio php "ci_edicion".
Te cuento lo que vi y vos despues me diras si hay algun motivo particular por el que este asi.

Veo que en lugar de invocar los objetos via el metodo $this->dep($rol) o $this->dependencia($rol) se esta haciendo una llamada a toba::componente_por_id($id), esto puede ser causa del problema que estas viendo.

El metodo que estan usando genera una nueva instancia para el componente cada vez que se invoca, esto implica que el estado interno de esa instancia no es el mismo… lo mismo para el resto de los objetos, sea DR, DT, CI, etc.

El CI guarda internamente (ademas de realizar alguna inicializacion) la instancia de sus dependencias la primera vez que se invocan, con lo cual cada llamada via el metodo dep() accede al mismo objeto cacheado, esto hace que los estados internos se mantengan.

En el caso del DR/DT, eso implica que internamente tiene cargado lo que vos le solicitaste via la seleccion del cuadro… si en lugar de usar el metodo set() (que sirve tanto para insertar como modificar) hubieras ido por el metodo modificar_fila(), te hubiera informado un error al intentar modificar una fila inexistente. Se dio una combinacion de varios factores, lo que derivo en que se realizaran inserciones cuando querias modificar.

Otro beneficio de usar el metodo dep() en lugar de accederlo por ID, es que podes reutilizar el codigo… mientras las dependencias tengan el mismo rol en la operacion (por rol me refiero al ID que le asignas cuando se agregan al CI), podes utilizar distintos objetos. La invocacion por ID directa te restringe mucho en ese sentido, ya que unicamente podes usar un Ci interno especifico con ese Ci navegacion.

Un ultimo detalle, los formularios y filtros tambien reciben los datos via el metodo set_datos() el retorno de los mismos se sigue aceptando por compatibilidad hacia atras… pero no es una buena practica porque genera un acoplamiento innecesario cuando se realizan extensiones.

Creo que reemplazando las llamadas a componente_por_id(id) x $this->dep(rol) en ambos Cis, el problema con la modificacion se deberia solucionar.

Si existe algun motivo por el que este asi el codigo o cualquier inquietud que tengas, decime y vemos como lo vamos solucionando.

La carga del DT la estoy haciendo al seleccionar una de las filas de alguno de los listados en el archivo ci_navegacion linea 72.
La logica de la carga esta bien, solo miraria lo que te comente arriba.

Saludos

Buenas Tardes.

Fabulosa explicación, en efecto el problema estaba en obtener el componente por fuera del contexto vía toba::componente_por_id, esto lo hice porque al tratar de usar $this->dep me tiraba el error “OBJETO [cargar_dependencia]: No EXISTE una dependencia asociada al indice [datos_exp].” , este ultimo error se debía a que como tenia el mismo php para los ci’s abm expedientes y bandejas cuando se invocaba al $this->dep se estaba llamando desde el contexto de bandejas (estimo) que no tiene a datos_exp como dependencia (porque es dependencia del nodo padre: ci abm expedientes). Gracias a que me señalo que necesitaba el código de los tres ci caí en que necesitaba un archivo php independiente para el ci bandejas, así que hice eso y después pude acceder a la relación “datos_exp” desde el nodo de bandejas con $this->controlador->get_relacion.

También quite los set_datos() que cargaban los cuadros de listado como recomienda, gracias.

En definitiva, el update se hace correctamente y el ABM ya esta funcionando, así que por mi esto queda como solucionado.

Le agradezco mucho por su tiempo y dedicación.

Saludos Cordiales.
Juan.

Hola Juan,

en realidad era lo contrario, osea usar set_datos() para todos los metodos conf__xx en lugar de simplemente hacer el return.

En definitiva, el update se hace correctamente y el ABM ya esta funcionando, así que por mi esto queda como solucionado.
me alegro que se haya solucionado.

Saludos

Buen Día.

Ups. lo entendí al revés, ahí lo corrijo, gracias de nuevo.

Saludos Cordiales.
Juan.