Problema con datos Reales

Hola resulta que tengo un campo importe de tipo real en la base, cuando quiero modificar un registro donde el monto es por ejemplo 11234,65 desde el formulario, me sale este error:

Error de concurrencia en la edición de los datos.

Mientras Ud. editaba esta información, la misma fue modificada por alguien más. Para garantizar consistencia sólo podrá guardar cambios luego de reiniciar la edición.

Ahora si lo grabo con un monto en 11234,60 no de ese error o por ejemplo con un monto de 9889,45 lo graba bien.
Que puede ser, hay algún problema con los datos de tipo real, es mejor usar doble precisión?

Cristian,

es un problema de representacion, Postgres guarda los campos float/double con precision variable y es distinta de la que maneja PHP… por lo tanto cuando se intenta hacer la SQL para determinar si un registro en la bd se modifico, devuelve un falso positivo… ya que “3.14159” != “3.14159265359”… una opcion es forzar a Postgres a utilizar cierta precision, la otra es forzar a PHP y esperar que no tome en cuenta los ceros restantes postgres al realizar la consulta.

Lo mejor para ese caso seria definir el campo en cuestion como NUMERIC o DECIMAL y especificar precision/scale… pero el tema es que tenes que asegurarte de no enviar un valor que supere la cantidad de decimales… porque ahi hace el redondeo postgres. Por otra parte, precision determina la cantidad maxima de digitos del valor… con lo cual tenes un tope maximo tambien.

Saludos

Perdon que resucite este hilo viejo, pero estoy con exactamente el mismo problema. A mi me pasa que en el WHERE del UPDATE me agrega una condicion con un numero que es “float”, y que por migracion de datos “viejos” no es posible truncar ni redondear. Pero la verdad es que esa condicion del where es por Toba, no porque sea necesaria. No hay manera de indicarle al Datos Tabla con que campos construir el where y que no utilice todos?

Encontré esto del Lock Optimista, pero no tengo claro desde donde se desactiva:

https://github.com/SIU-Toba/framework/blob/develop/php/nucleo/componentes/persistencia/toba_ap_tabla_db.php#L1080

Hola Tomas,

si no es necesario lo podes desactivar via toba_editor, modificando el datos_tabla correspondiente en la pantalla de datos generales en la parte inferior.
Sino via codigo, se puede desactivar en runtime invocando este metodo.

Al AP llegas via este metodo del DT que podes invocar antes del sincronizar si queres.

Saludos

Ok con lo de desactivarlo vía código, pero no encuentro la opción desde el editor. Te paso adjunto un screenshot del DT en cuestión (Estoy en Toba 3.3). Cual de esas opciones sería? O algo me estoy perdiendo?


Screenshot from 2020-12-29 10-16-23.png

Screenshot from 2020-12-29 10-16-23.png

Ok, leyendo en 1 encontré que esto es a nivel del Datos Relación, voy a ver si con eso puedo saltear el problema.

Confirmo que desactivar el locking optimista hace que no se comparen los datos en el where, y eso “esquiva” el problema de los floats. Gracias por la ayuda.

Hola Tomas,

barbaro… si, yo fui por el codigo y enganche por el DT… pero en toba_editor aparece en el DR como bien mencionas.

Saludos