Formatear un campo varchar

[gcb77]

Hola, buen dia.

Tengo el siguiente problema.

Tengo en una tabla un campo que es de tipo varchar, y en ese campo debo guardar un dato que es resultado de un calculo, el dato a guardar va a ser un float, pero al dato a guardar quiero darle el siguiente formato.

Ejemplo: el dato flotante que debo guardar es 9525685.25
y yo quiero guardarlo en el campo varchar de esta manera 9,525,685.25

mi problema es como darle el formato de separación de miles al guardarlo.

Muchas gracias por la ayuda

[Libras]

si buscas en google encuentras:

http://lobyte.blogspot.com/2008/08/f...ro-en-sql.html

pero ya que veo que te da flojera te dejo el ejemplo:

Código SQL:

DECLARE @val FLOAT
SET @val = '9525685.25'
SELECT CONVERT(VARCHAR(50), CONVERT(money, @val), 1)
 

[iislas]

Libras !!!, usted perdiendo la paciencia, querido amigo, unas vacaciones para retomar el animo....

[Libras]

Iniciado por iislas

Libras !!!, usted perdiendo la paciencia, querido amigo, unas vacaciones para retomar el animo....

Tiene Razon iislas me faltan unas vacaciones :P jejejejeje, creo que ya entiendo cuando decia que le faltaba paciencia :S

[matanga]

gcb77, en general, el formato de un valor no es algo que se guarde en la base, deberías definir una columna numérica para el dato calculado, y cuando sea necesario, aplicar una función en el select para el formato, de esta manera mantienes la posibilidad de realizar operaciones matemáticas o de agregado (avg, sum, max, etc) además de optimizar el espacio de almacenamiento. Un ejemplo similar son las fechas, que se guardan en un tipo date y con la función convert las puedes visualizar como '01/01/2012', '01-01-20120', etc.

Saludos

[iislas]

Bueno, ya se ha mencionado que el FORMATEO o COSMETICA de presentacion de los datos, no es una funcion que deba hacer el motor de la base de datos, esta, deberia estar en la capa cliente.

[matanga]

Iniciado por iislas

Bueno, ya se ha mencionado que el FORMATEO o COSMETICA de presentacion de los datos, no es una funcion que deba hacer el motor de la base de datos, esta, deberia estar en la capa cliente.

Esto varía según el caso, puedes tener una aplicación con usuarios de diferentes países donde sea más interesante que la capa cliente de formato a las fechas en función de la configuración regional de Windows, o puedes tener un proceso de extracción de datos o ETL que genere un fichero .txt con columnas de ancho fijo como input de datos para otro sistema y sea más interesante definir el formato de las fechas en las consultas SQL.

Saludos

[iislas]

matanga

El intercambio internacional de datos es ANSI, por tanto las fechas SIEMPRE deberian ir en YYYYMMDD HH:MM:SS

¿Cierto?

[matanga]

El intercambio internacional de datos es ANSI, por tanto las fechas SIEMPRE deberian ir en YYYYMMDD HH:MM:SS

Cierto, el estándar ANSI/ISO define el formato como 'YYYY-MM-DD hh:mm:ss' o 'YYYYMMDD hh:mm:ss', pero la realidad es que no siempre se aplica, haciendo un poco de memoria recuerdo dos casos, uno era el proceso de carga de un datawarehouse que solo podía leer datos desde un fichero de texto con columnas de ancho fijo y formato fecha 'MMDDYYYY', el otro era un sistema de reportes que generaba listados a partir de ficheros XML, y cada XML se generaba a partir de una consulta a la base, pero el sistema no interpretaba tipos, leía todos los nodos como varchar por lo que no podía reconocer una fecha para darle formato.

Estoy de acuerdo que es preferible dar formato a los datos en la aplicación, pero también hay casos válidos donde puede ser perfectamente una función de la base.

Saludos

[iislas]

100% De acuerdo, simplemente.....Cuando son de INPUT (Entrada)