Cita: estoy haciendo pruebas pero no hay maneras
he probado con
double
(11,2)
float
(11,2)
decimal
(11,2)
11 numero y 2 van a ser decimales pero cuando encuentra el punto
600.00
1.00
quiero entrar por ejemplo 600.000 o 1.000.000 euros
no tendría que ser cuando coja una , que me ponga 2 decimales
y si pongo 11 sin los 2 decimales tampoco funciona
El problema es que estás confundiendo
representación con
almacenamiento.
Los puntos y comas de la representación numérica son cosas que se implementan en las interfaces gráficas para que el usuario entienda los números en un lenguaje natural. Pero los separadores de miles carecen de sentido a nivel de almacenamiento, no se los representa y tampoco se los almacena.
En la realidad, los números se almacenan como binarios y no como cifras (este es un error muy común ente los que se inician en programación y bases de datos), y como binarios es como se los maneja incluso en la memoria RAM. Hay razones fundamentales por las que esto es así. Así pues, un valor como 2356, se almacenará realmente como 00001001 00110100, pero como esto está codificado, como hexadecimal en realidad usa 2 bytes para guardarlo y no cuatro.
¿Más o menos se entiende la ida?
Entonces, los DBMS no comprenden nada que no sea número cuando el contexto es un campo de tipo FLOAT, REAL o DECIMAL, para que un valor dado se almacene correctamente, debes
escribirlo correctamente. Por caso: El número
6.000.000,00 se debe escribir en la sentencia como
6000000.00 . Notarás que estoy eliminando los puntos de miles y cambiando la coma por el punto; esto último es simplemente porque los DBMS interpretan un estándar heredado del inglés done el punto es siempre separador de decimales.
Normalmente, cuando estás programando en un lenguaje dado, el mismo lenguaje de programación te aporta las funciones necesarias para pasar el valor como parámetro d la sentencia y darle el formato correcto. No es algo de lo que debas ocuparte manualmente. Hay métodos para manejar esto.
Lo que
si debes recordar es que luego, cuando recuperas el valor debes también usar las funciones que el lenguaje tiene para darle al número el formato que el usuario entienda.
Sé que eso parece molesto, pero es así como se hacen todos los programas. Lograr que una aplicación
haga algo es fácil. Lo que más tiempo lleva es validar lo que entra y formatear lo que sale, sin contar la infinidad de horas que te lleva programar los formularios para que el usuario no haga lo que no debe (como enviar los datos in antes haber llenado todo, o que presione un botón antes de que los datos terminen de cargarse, por ejemplo).
Respecto al euro, lo que yo haría en tu caso sería tener una tabla de monedas cuya PK pondría en la tabla donde los precios aparecen para que especifique el tipo de moneda usado en ese mismo precio. No lo pondría como símbolo, ya que los lenguajes de programación suelen tener cómo resolver eso, sino como ID numérico. A mi entender sería más simple.