tipo de dato

[susan_]

hola!.. espero que puedan ayudarme.. es algo sencillo.. pero estoy en mis primeros pasos.. que tipo de dato debe ser un campo que va a contener una catidad monetaria?..osea que lleva punto decimal?..segun yo debe ser decimal.. o float.. o algo asi no?pero en la aplicacion me arroja el siguiente error..You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''123123123123.09')' at line 1

[susan_]

helllllllllppppppppppppppppppppppp

[Genetix]

Debe ser decimal.
Eso error te arroja al insertar o al crear la tabla?

[susan_]

al inseertar

[Genetix]

como haces la inserción? puedes poner el query?

[susan_]

Código PHP:

  $query_Recordsetinsert = "insert into reg_activ (cont_activ, robra, ridfase, ridsubf, activ, t_moneda, monto, lb) values ('".$cont_activ."','".$robra."','".$ridfase."', '".$ridsubf."','".$activ."','".$t_moneda."','".$monto."','".$lb."')"; 
$Recordsetinsert = mysql_query($query_Recordsetinsert, $conex) or die(mysql_error());  
   

Código:

el campo es el de monto

[xcars]

si $monto es igual a este valor 123123123123.09 no estoy seguro, pero es un numero demasiado grande.... ahorita no recuerdo bien, pero los tipos de datos tienen limites de hasta donde pueden manejar numeros, mira el manual de mysql y mira los tipos de datos, a ver el rango de decimal... pro estoy seguro que eso es

$monto=123,123,123,123.09

prueba con un valor pequeno, digamos 1.25 a ver si te funciona

[gnzsoloyo]

Lo que te confiene es definirlo como FLOAT o DOUBLE, ya que cuando manejas valores monetarios el problema no está en los decimales sino en los redondeos que se hace y que en su acumulación pueden representar cifras siderales.

Me explico: Si quisieras recortar el quinto decimal y transferirlo a otra variable, en un balance de cuentas de ventas, podría parecer una nimiedad (es un diezmilésimo), pero imagínate el efecto en el balance de una empresa que realiza 120.000 transacciones diarias (no hablemos las que hace eso en un minuto): El resultado sería la acumulación de 12 unidades monetarias por cada día... es decir, alquien se está quedando con 360 unidades monetarias en un mes, y que pertenecen a la empresa. No es una exageración, desde hace años las empresas saben que ese tipo de fraudes son posibles, cuando los sistemas no calculan bien las fracciones por detrás del máximo de decimales representables. Es una historia que viene desde la época de los maiframes de los años 50 y 60...

En definitiva esto se soluciona de una forma simple:
1. Los almacenamientos se hacen como DOUBLES o FLOAT por su mayor precisión (técnicamente hablando el tipo CURRENCY en algunos DBMS es un REAL, DOUBLE o FLOAT de la máxima precisión del sistema).
2. Las representaciones de los datos para las consultas se hacen con DECIMAL(X,2), siendo X la cantidad de decimales enteros a representar en el sistema. Toda otra solución es sospechosa en una auditoría...
No te olvides nunca que lo que debes representar es lo que el usuario debe ver, pero eso no quiere decir que eso es lo que se deba almacenar (un ejemplo sería que las SUMAS de una factura no se almacenan, se almacenan los valores que se sumarán; los valores calculables generan almacenamiento inútil y ocupan espacio).