Decimales

[pablinweb]

Buenas,

Tengo varias paginas que ingresan datos y actualizan, el dato en especial del que hablo es un número que puede o no tener decimales, tengo sql server 2000 y el campo lo tengo como float, hasta hace unos días estaba todo bien pero hoy ingreso el número por ejemplo 11.5 y me guarda 115
pero si lo ingreso con el query analyzer o desde visual lo ingresa bien
se puede haber cambiado sola alguna configuración del iis o de alguna otra cosa?

[u_goldman]

qué LCID está utilizando tu aplicación? y el servidor que idioma tiene configurado, podría ser por ahí...


Salu2,

[pablinweb]

lo tengo como Español México, y tiene el punto como separador decimal y dos lugares para los decimales. LCID ninguno, o por lo menos no lo especifiqué en el código, pensé que era solo para las fechas, necesito ponerle alguno?

[dobled]

prueba grabando con 11,5

[Muzztein]

Iniciado por pablinweb

pensé que era solo para las fechas, necesito ponerle alguno?

LCID (LocaleID)

[pablinweb]

Iniciado por dobled

prueba grabando con 11,5

Si le pongo la coma me lo guarda como punto

[Muzztein]

me tinca que la BD esta en ingles. y el web server esta en español

, para la separacion de los miles y el punto para la separacion de los decimales.


para la BD 11.5 es 11.5
mientras que para el web 11.5 no tiene sentido y lo convierte a 115

[dobled]

Iniciado por pablinweb

Si le pongo la coma me lo guarda como punto

chequea la configuracion regional del equipo>numeros y moneda

[pablinweb]

tengo en la configuración regional el punto como separador de decimales.
desde asp le pongo 11.5 y lo guarda como 115 y si le pongo 11,5 lo guarda como 11.5 pero si lo pongo a mano en la bd 11,5 lo guarda como 115 y 11.5 como 11.5, no sé porque si hace unos días atras andaba bien, pero bueno, que tengo que hacer para que desde ASP me tome siempre el punto como separador de decimales?

[Muzztein]

lcid como USA

[pablinweb]

yo tengo <%@LANGUAGE="VBSCRIPT" CODEPAGE="1252"%> en todas las paginas (que en realidad no sé ni que significa el codepage), lo tengo que cambiar por <%@LCID = 1033%> o lo puedo poner en el global.asa? o dejo el codepage y agrego el lcid?

[Neuron_376]

Como le pasas el campo a la base de datos ?
insert into tabla (11.5)

El campo de que tipo es ?
Cuando lees el campo que valor te da ?
Ya revisaste mirar el campo directo en tu servidor de bases de datos?
Probaste la consulta directamente en tu servidor de bases de datos?

Haz esas pruebas

[pablinweb]

lo guardo con recordset
Rs("VL_EXCHANGE") = trim(request.Form("txtVL_EXCHANGE"))
y si miro el valor del txtVL_EXCHANGE me lo está pasando bien desde el formulario
el campo es un float
si leo uno de los que guardé antes cuando andaba bien me lo muestra con el punto
ya revisé directamente en la bd, leiste los post anteriores? porque salvo la forma en que lo guardo ya escribí todo lo que me preguntas...

[Neuron_376]

Intenta guardarlo asi:

Rs("VL_EXCHANGE") = Cdbl(request.Form("txtVL_EXCHANGE"))

[Neuron_376]

Solo te falt decirme, como lo lees despues de que esta guardado y qeu te muestra

[pablinweb]

lo muestro con <%=Rs("VL_EXCHANGE")%> y me lo muestra bien
con Rs("VL_EXCHANGE") = Cdbl(request.Form("txtVL_EXCHANGE")) lo guarda bien pero la verdad que estoy buscando algo un poco más global porque ya tengo todo el sitio armado así y es un garrón entrar a cada pagina y cambiarlo, por eso preguntaba sobre el lcid y el codepage para ver si por ahí podía solucionarlo

[Neuron_376]

Respecto a seguridad, te dije a proposito que lo probaras para que lo comprobaras tu mismo...

Cada vez que mandes un dato a SQL Server o a cualquier base de datos, asegurate que el dato que estas mandando corresponde al tipo de dato de la base de datos, si te lo hubiera dicho antes hubieras pensado que estoy mal, y que siempre funciona mandar los datos como caiga, pero ahora te das cuenta de que no.

Cdbl Convierte un dato a tipo DOUBLE, el cual encaja en float como lo tienes, aunque creo que tambienexiste Cflt pero no recuerdo, igaul Cdbl funciona, en tu caso como estas actualizando el campo con el recordset fue el error, el recordset dice:

rs("campo") = variables
VARIABLE_TIPOX = VARIABLEY

Entonces ahi es donde entra la confusion y lo guarda mal, con un insert no hubiera pasado porque la interpretacion de tipos de variables lo dejas directo en el SQL Server, ya que le pasas una simple cadena (consulta)

Bueno, mi consejo, cambia todo tu sitio a enviar los datos correctamente eso te ahorrara futuros dolores de cabeza, y tambien cuando recuperes variables haz esto:

variable = Cdbl(rs("campo"))

Porque tambien es posible que cuando manejas valores asi:

variable = rs("campo")

total = total + variable

Eso te de un error.

Bueno te lo dejo como consejo, ya lo comprobaste, entonces es mejor siempre en tu codigo asegurarte que una variable es exactamente del tipo que necesitas.

suerte!!

NOTA: Recuerda que cuando no eres dueño del hosting, no puedes cambiar nada en la configuracion, por eso es regla que tu codigo use el mejor metodo posible siempre, sin preocuparte por x configuracion en tus servidores.

[pablinweb]

ta barbaro lo que me dices, pero porque con la maltida coma me lo guarda bien?

[Neuron_376]

Relamente no se, pero si se que son metodos inseguros .. Jejeje, creeme, he tenido muchos errores raros en todo lo que llevo programando y por eso lo digo.

Y casi siempre, no necesitas soluciones rebuscadas, sino las mas sencillas, "Hacer bien las cosas", :-p me ha pasado mucho.

[dobled]

pablinweb he hecho la prueba modificando las propiedades de la configuración regional y verdad que afecta bastante, seguro que está correcta. e incluso te muestra diferente hasta en los campos datetime en el Admin-corporativo de SQL

[pablinweb]

si, lo tengo con punto tanto para número como para moneda, está así 123,456,789.00, fijate que en el admin-corp tambien se vé el cambio en los campos de número. Con el LCID me cambia lo que vé el usuario pero la bd sigue igual así que eso de que con el LCID no importa en que servidor lo pongas es todo un chamullo porque la base de datos no toma en cuenta esto. Estoy viendo de tomar siempre dos decimales y guardarlos sin coma ni punto de manera que mil lo guardaría así 100000 y hacer una función que lea e interprete el punto o la coma como separador para quitarselo y agregarle los ceros necesarios y otra que muestre y siempre ponga el punto en 3er lugar a la derecha. Lo que dice Neuron es valido, pero si el usuario pone una coma en lugar del punto cuando lo intento pasar a doble me dá error y tal vez en otro equipo el caso sea al reves, por eso no creo que eso sea hacer las cosas bien.

[dwaks]

Siempre que trabajo con numeros que sean usado para calculos matematicos los uso sin puntos y sin comas.

Esto nos ayuda a evitarnos dolores de cabezas de malos calculos y muchos decimales. El fin es que puedes hacer sumas de esta manera.

Si tienes en la base de datos el valor 115 que en realidad para ti es 1.15 lo puedes sumar con 300 que es 3.00.

Como hacerlo es simple.
115 + 300 = 415

Pero cuando lo muestres en tu pagina web la mejor manera es:
cantidad = 415 / 100 ' Cantidad sera igual a 4.15

Si quieres darle mas formato a esto puedes usar la funcion:
FormatNumber(cantidad,0)

Trata de investigar mas de las formas de mostrar los datos de esta funcion.

Siempre la cantidad que tengas en la base de datos sin punto y coma lo puedes dividir entre 100 y te dara el numero correcto y con FormatNumber le dices al asp como mostrar ese numero y con cuantos decimales.

Bueno espero te ayude.

[Neuron_376]

pablinweb, creo que si entendi bien lo que estas diciendo, es lo mismo que dije yo, mira lo que quieres hacer se llama VALIDACION.

1. Pedir numero a usuario (FLOAT - DOUBLE) :

- 12,500.50
- 13600.60

2. Creas ValidarDouble(ByVal varVar)

- BUSCAR COMAS Y QUITARLAS: strReplace (varVar, ",", "")
- Verificar que sea un CDBL, IsNumeric(varVar)
- Si si entonces var = Cdbl(varVar)
- Si no, entonces, LA CANTIDAD QUE METISTE NO ES VALIDA.

3. Tu programa recibe esas cantidades, entonces:

- dblVar = ValidarDouble(Request.Form("cantidad"))
- rs("campo") = dblVar

Y para mostrar cantidades usas justamente FormatNumber como menciono dwaks, o bien creas otra funcion personal, pero para el caso lo que mencionas es muy parecido o igual a lo que te decia antes, simplemente asegurarte siempre de pasarle a tu base de datos valores que sabes perfectamente que son correspondientes a lo que se necesitan.

Y tendras que cambiar todo tu codigo para asegurarte de eso, y tomar esa clase de medidas, no solo con los float, sino con int, str, etc.

Suerte!!

NOTA: Solo que con este metodo de validacion, sigues respetando estandares de SQL, ASP, etc., y no te metes en tantos problemas como lo que estas pensando hacer, es lo mismo, VALIDACION, pero con otro enfoque

[pablinweb]

me parece que ya me estas delirando...
lo que digo es que la bd respeta la configuración regional del equipo entonces no sé si tomar la coma o el punto, aparte como el sitio lo usan desde varios paises creo que es medio molesto obligar al usuario a usar el punto si está acostumbrado a usar la coma por eso voy a hacer una función que saque la coma o el punto y guardar el numero como un entero

[Neuron_376]

Cierto, si alguien no quiere usar el punto para los decimales pues esta bien, pero creo que eso lo controlarias mas facil poniendo mensajes de como deben escribir las cosas, y mandando mensajes de error controlados desde ASP, asi seria mas facil el control para ti, pero bien, entiendo tu punto y tienes razon.

Suerte!!

[dwaks]

Si la gente mete en un input type text el valor 4.15 solo es de agarrarlo en asp y multiplicarlo por 100 y dara el formato que usa la base de datos.

ejemplo:
cantidad = Request.Form("cantidad") 'aqui es igual a 4.15
cantidad = cantidad * 100 ' aqui ya es igual a 415

Y ese formato es correcto para la base de datos.

La gente de forma mundial usa siempre las coma para determinar miles y los puntos para decimales por eso agarra ese valor que ellos mandan y multiplicalo por 100 asi siempre lo e realizado en sistema de calculos de numeros y nunca a fallado.

Saludos.

[Neuron_376]

dwaks, pero pablinweb no quiere eso, el quiere que cualquier persona escriba el numero como se le antoje, entonces el debe hacer algo para respetar todas esas formas de escritura, por eso su idea de quitar todo, sumar dos espacios, al leer decir, esta cantidad menos dos puntos, etc. Lo cual me parece muy complicado, pero asi es como el quiere manejarlo, con la idea de que en todos los paises puedan escribir los datos como estan acostumbrados..

Se va a llevar grandes sorpresas con eso , si para mostrarlos es un problema, ya me imagino para recuperarlos

[dwaks]

Estan enrredando todo, lo confunden mas ya que sigo en mi punto de que el dinero como los numeros son iguales para todo el mundo.

Si alguien no lo escribe correcto es porque no sabe contar o nunca a visto la diferencia de decimales con miles asi que porfavor no enrreden lo que es obvio.

Pero bueno es mi punto de hacer las cosas, disculpa sino soy muy claro pero creo que no estoy equivocado.

Saludos.

[Muzztein]

uf ..........

[Neuron_376]

Yo nunca dije que estuvieras mal... solo que no es lo que quiere pablinweb, mi metodo tambien lo rechazo y dijo que no le servia , pero aclarando, los numero no son igual para todo el mundo, ni la forma como los escriben...

Manejo un sistema de currencys donde todos los usuarios pueden MIRAR los precios exactamente con la sintaxis de su pais, y vaya que fue complicado hacerlo, no dificil pero si laborioso, sin embargo para recuperar numeros, siempre he usado el metodo que dije abajo, donde el usuario simplemente escribe: 5100.50, etc. La coma no la tengo permitida, porque se de todos los problemas que esto trae, pero al momento de desplegar me doy mis lujos

80.50 E (para euros)

Lb 85.555 (para, no recuerdo)

$25,500.00 (pesos mexicanos)

Etc., existen muchos tipos, quienes solo usan comas, quienes usan solo puntos, ufff, no acabaria, son muchisimas combinaciones.

Por eso digo, si para mostrar ocupe una tabla de configuracion, ya me imagino para recuperar los numeros y validar todos los casos

Suerte!!