![]() |
Ayuda: "Record not found or changed by another user"
Hola,
Tengo un proceso que sumariza los detalles de una factura para determinar el importe e impuesto totales, en base a tales detalles. pe_regoper es un objeto que contiene propiedades (property) que escriben los datos a los campos de la tabla. También tiene asociado el ClientDataSet que accede a la tabla. Partidas es otro objeto relacionado a pe_regoper que contiene propiedades de las partidas, y su ClientDataSet, que accede a la tabla de partidas. if (pe_regoper.Cierre = 'N') and (not pe_regoper.Partidas.z_DataSet.EOF) then begin pe_regoper.z_DataSet.Edit; pe_regoper.TotalImporte:= 0; pe_regoper.TotalIVA:= 0; with pe_regoper.Partidas.z_dataSet do begin First; while not Eof do begin pe_regoper.TotalImporte:= pe_regoper.TotalImporte + pe_regoper.Partidas.Importe; pe_regoper.TotalIVA:= pe_regoper.TotalIVA + pe_regoper.Partidas.IVA; next; end; end; pe_regoper.z_dataSet.Post; if TClientDataSet( pe_regoper.z_dataSet ).ApplyUpdates(0) > 0 then TClientDataSet( pe_regoper.z_dataSet ).CancelUpdates; end; En el debugger veo que entra a la condición sin problema, y efectúa las operaciones de totalización correctamente. El problema viene al aplicar el ApplyUpdates, obtengo "Record not found or changed by another user". Cada ClientDataSet está asociado al Provider, y este a su vez a un ZQuery de Zeos que conecta a MySQL 5. Uso Delphi 7 Qué podrá estar pasando? Gracias, Guillermo |
¡Hola!
Justo en la parte inferior de esta página aparecen varios enlaces a otros hilos con el mismo mensaje de error. El problema podría estar en lo mismo que encontramos en esta otra situación: http://www.clubdelphi.com/foros/showthread.php?t=63945 Muy importante: Usa las etiquetas especiales para darle formato al código que publiques, haciendo que quede más legible. :) Saludos. Al González. |
Hola Al,
Gracias por la respuesta. Estoy viendo en el DataModule las propiedades del Provider y del ZQuery en lo que son los campos: La propiedad SQL del ZQuery contiene:
Dado que se trata de una vista y no una tabla, en el evento del Provider OnGetTableName, tengo:
Esta mecánica la uso en otras vistas, y me funciona bien. Lo diferente de los otros casos, es que en este que tengo problemas, el query tiene parámetos "where": where regoper_id= :regoper_id En el Provider, el UpdateMode lo tengo como "upWhereKeyOnly", y he comprobado tanto en los campos del ZQuery como del ClientDataSet, que:
En el enlace que me indicas, Bauhaus tenía el problema de que externamente se le estaba modificando el "upWhereKeyOnly" a "upWhereAll", más no entendí muy bien de qué manera podría rastrearse eso en el código. Como comentaba, tengo otros 4 ZQueries en donde no tengo problema con el ApplyUpdates, excepto con este, que tiene un parámetro "where" en la sentencia SQL y que uso para agrupar los detalles asociados a una tabla maestro. Qué podrá ser? Gracias, Guillermo |
Como elemento adicional, y en caso de que pueda ayudar a que encontremos una pista del problema (esperando no confundir más):
En dxDBGrid en que muestro los registros de detalle, filtrados según el registro "master" o encabezado, al momento de seleccionar uno para modificar, sucede algo extraño: 1- Si es la primera vez que entro al grid y elijo un registro a modificar dentro de una forma con el mismo dataSource, se elige bien el registro y se muestra bien en la forma. 2- Si después, navegando en el grid, elijo visualmente otro registro a modificar, la forma toma otro registro distinto al elegido y al regresar al dbgrid, la lista parece volverse loca, ya que el cursor se reposiciona en el número de registro que elegí, pero mostrando el registro equivocado tomado por la forma. Si se hace repaint al dbGrid, se redibujan correctamente los datos. Esto no sucede en los dbgrid en que no hay Params en el ZQuery. Gracias |
Hola de nuevo Guillermo.
Por lo que nos comentas, creo que sólo te falta la bandera pfInKey en el campo ID, ya que de otra manera, por tratarse del modo upWhereKeyOnly, no se tomaría en cuenta el campo. En cuanto al comportamiento que mencionas de la rejilla, tal vez se trate de un problema aparte. Primero dinos cómo te funciona con la bandera pfInKey debidamente activada. Saludos. Al González. :) |
Hola Al,
Me he asegurado de que en el id de la tabla/view se tengan las banderas [pfInUpdate,pfInWhere,pfInKey] tanto en el ZQuery como en el ClientDataSet. ya están puestas, de hecho estaban en el ZQuery, y en el ClientDataSet solo faltaba el "pfInKey". Lo volví a ejecutar y aún marca el error :( |
OK, ¿podrías mostrarnos el contenido de la vista regoper_part_v? Esto para saber cómo estás obteniendo el campo ID.
|
select
`regoper_part`.`regoper_part_id` AS regoper_part_id`, `regoper_part`.`regoper_id` AS `regoper_id`, `regoper_part`.`proveedor_id` AS `proveedor_id`, `proveedor`.`prv_rfc` AS `PRV_RFC`, `proveedor`.`prv_nombre` AS `PRV_NOMBRE`, `regoper_part`.`rpp_numpartida` AS `RPP_NUMPARTIDA`, `regoper_part`.`rpp_numpoliza` AS `RPP_NUMPOLIZA`, `regoper_part`.`rpp_numfactura` AS `RPP_NUMFACTURA`, `regoper_part`.`rpp_mesfactura` AS `RPP_MESFACTURA`, `regoper_part`.`rpp_iva` AS `RPP_IVA`, `regoper_part`.`rpp_importe` AS `RPP_IMPORTE`, `regoper_part`.`rpp_pendientespoliza` AS `RPP_PENDIENTESPOLIZA` from (`regoper_part` left join `proveedor` on((`regoper_part`.`proveedor_id` = `proveedor`.`proveedor_id`))) |
Hola Al,
Creo que nos estamos yendo por la tangente. El problema no es actualizar un registro en "regoper_part_v", sino en la tabla padre: "regoper". El problema original viene del código inicialmente mostrado en el hilo (aquí un poco más legible):
Es en el ApplyUpdates que tengo el error ya mencionado. Ubiqué un ZSQLMonitor, y aquí está el código que genera para hacer la actualización:
La verdad no veo problema; pero en fin, he aquí más datos. El Provider de regoper_v tiene el evento correspondiente:
Y el SQL del ZQuery de regoper_v es:
La vista consiste de:
|
Ahora veo que todo el tiempo te referías a la tabla maestra, me confundí cuando mencionaste también la tabla de partidas.
Pues la primera pregunta que salta es, ¿existe un registro en la tabla maestra con el ID 689349199046620201? Por cierto, sospechosamente largo. ¿Es un "Big Int"? Me gustaría seguir revisando esto con mayor detenimiento, pero no sólo de postear vive el hombre. Tal vez mañana me dé algo de tiempo... Saludos. :) |
Al,
Agradezco tu tiempo y tu disposición de asistir en este tema :) Sobre tus observaciones: "689349199046620201", si ... los ID de las tablas son bigInt (Int64 en Delphi). Y si, el registro existe en la tabla. Las banderas de Provider para "regoper" están bien puestas en relación a "upWhereKeyOnly". Saludos y que tengas buen viernes! Guillermo |
Cita:
Cita:
|
Estimado Al....
No quememos más neuronas. Se trataba de un triste bug en los componentes ZeosLib versión 6.6.4 que presumen, es la estable. Es el segundo bug serio que les pesco... El primero lo pude arreglar yo en los fuentes, por que en sus foros nunca respondieron estas inquietudes... Ahora, reemplacé la conexión de Base de Datos y el ZQuery, por componentes dbExpress demo de DevArt para MySQL... y asunto arreglado. Ni modo... yo que ya estaba contento con ZeosLib ... :( Saludos y gracias por tu ayuda! Guillermo |
Que bien que hayas optado por los nativos dbExpress, pero aun así puede que valga la pena comentar de qué se trata el defecto (bug) que encontraste en los Zeos. Igual y resulta factible corregirlo o sacarle la vuelta mediante algún truco. :)
Por cierto, ¿tiene que ver con los BigInt? ¿por qué usas un entero tan grande como llave? |
Al,
Si, sería bueno saber las causas de este bug en particular, más lo desconozco. He posteado esta situación en los foros Zeos; desafortunadamente en los mensajes que he dejado, los tiempos de respuesta son de una semana, y eso es preocupante en un proyecto crítico. Saludos |
La franja horaria es GMT +2. Ahora son las 23:55:46. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi