Forums Últimos mensajes - Powered by IBM
 
Tags Palabras claves

Importar datos desde xml

11/08/2005 - 14:10 por Beren | Informe spam
Ayuda Hacer una pregunta
Hola,

No sé si me voy a explicar bien. La cuestión es que necesitamos importar a
Crystal Reports unos datos que tenemos en un xml que también hemos creado
nosotros dinámicamente a partir de una base de datos.

Antes de todo, aclarar que no nos enteramos demasiado, que digamos, de cómo
va el xml, y no porque no lo hayamos intentado, pero se ve que no somos
demasiado inteligentes ;-)

Pero bueno, yendo al problema en sí, el hecho es que tenemos un archivo .xml
con los datos y otro archivo .xsd (es decir, un xml schema de esos) en el
que está el tipo de datos, que por lo que hemos leido es como tiene que ser.
¿Y qué nos pasa? Pues lo típico: Como que en inglés los números los escriben
del estilo: 9,543.02, los datos que son decimales nos marcan error, ya que
nosotros los hemos escrito los números del estilo 9.543,02.

Ya sabemos que al crear el xml podríamos hacerlo cambiando puntos por comas
y lo inverso pero, siendo xml algo hecho teóricamente para ser lo más
estándar posible, ¿no existe un tipo de decimal estilo "español"? O ¿se
puede (o se debe) definir un tipo simple basado en el decimal?

He estado mirando por Internet y, aunque parezca mentira, no he encontrado
nada sobre el tema.

Espero que se me entienda. Al fin y al cabo, el problema es el típico y
eterno que tienen los programadores desde siempre, ¿no?

Bueno, un saludo y gracias por la posible ayuda.
email Siga el debateRespuesta 10 respuestasRespuesta Tengo una respuesta

Preguntas similare

Leer las respuestas

#6 Miguel Angel Campos
07/09/2005 - 09:31 | Informe spam
No es del todo como crees, si sólo se considerara lo que dicen los
anglosajones no iriamos bien encaminados.
Como te comenté en el otro correo la forma de representar los datos está
perfectamente definida en el estandar y utiliza lo que se llama una cultura
invariante, es decir, una forma de representar los datos definida
claramente. De todas formas tienes que tener en cuenta que este proceso se
basa en conversiones de tipos de datos a cadenas y tratamiento de estas
cadenas, si estas transformaciones las haces en un sistema operativo
configurado en Ingles (que se que no es tu caso) las conversiones de
DateTime a string las hará en formato anglosajón, y si el programa que lee
el fichero XML resultante está instalado en un SO en español intenta
convertir la cadena a DateTime considerando unas reglas.
Si utilizas .NET en tu proyecto puedes modificar este comportamiento,
mediante la utilización de la clase CultureInfo.
Te adjunto un link por si te sirve de algo:
http://www.codeproject.com/dotnet/d...format.asp

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Beren" escribió en el mensaje
news:
Perdona Patricia, no había visto el mensaje. La verdad es que me ayudó un
amigo con un pequeño programa en Visual Basic. Por tanto, supongo que debe
ser algo similar a lo que ha enviado skar.

Por cierto, he estado buscando la solución a mi problema y me parece que
va
a ser la que ya tenía: Variar el xml poniéndole el tipo de datos "a la
inglesa" para así poder importarlo desde Crystal. La verdad es que,
después
de leerme un montón de documentos, no he sido capaz de encontrar una
solución mejor. Lo siento Miguel Ángel, pero es lo máximo que he
conseguido
con tu ayuda.

Hay algo que me sorprende, y es que el problema que tengo yo no lo tenga
más
gente. Lo digo porque he estado buscando por ahí y no he encontrado nada.
Explicaré exactamente mi caso:

Tengo datos en archivos de COBOL y quiero mostrarlos en un informe de
Crystal Reports. En vez de hacer un archivo de texto plano separando los
campos con puntos y comas, pensé: "Será mucho mejor hacerlo con xml, que
así
puedo marcar el tipo de datos y operar luego con ellos en Crystal". Pero
por
lo visto, a los no anglosajones no se nos tiene en cuenta y los datos
tienen
que estar en inglés. Pues nada, a fastidiarse y a tenerlo en cuenta en el
momento de generar el archivo.

Un saludo.


Respuesta Responder a este mensaje
#7 skar
07/09/2005 - 18:53 | Informe spam
Tambien, pueden tener en cuenta que los documentos xml tienen que tener el
encoding especifico a cada lenguage (gringo UTF8)
otra cosa que se puede hacer, es el usar XML Schema y crear un Datatype
especifico para trabajar con fechas y numeros NO anglosajones:
dia: 22 de Julio de 2005 22/07/2005 versus 07/22/2005

"Miguel Angel Campos" <SPAMmacampos ARRUBA .idesarrollaSPAM.com> wrote in
message news:
No es del todo como crees, si sólo se considerara lo que dicen los
anglosajones no iriamos bien encaminados.
Como te comenté en el otro correo la forma de representar los datos está
perfectamente definida en el estandar y utiliza lo que se llama una


cultura
invariante, es decir, una forma de representar los datos definida
claramente. De todas formas tienes que tener en cuenta que este proceso se
basa en conversiones de tipos de datos a cadenas y tratamiento de estas
cadenas, si estas transformaciones las haces en un sistema operativo
configurado en Ingles (que se que no es tu caso) las conversiones de
DateTime a string las hará en formato anglosajón, y si el programa que lee
el fichero XML resultante está instalado en un SO en español intenta
convertir la cadena a DateTime considerando unas reglas.
Si utilizas .NET en tu proyecto puedes modificar este comportamiento,
mediante la utilización de la clase CultureInfo.
Te adjunto un link por si te sirve de algo:
http://www.codeproject.com/dotnet/d...format.asp

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Beren" escribió en el mensaje
news:
> Perdona Patricia, no había visto el mensaje. La verdad es que me ayudó


un
> amigo con un pequeño programa en Visual Basic. Por tanto, supongo que


debe
> ser algo similar a lo que ha enviado skar.
>
> Por cierto, he estado buscando la solución a mi problema y me parece que
> va
> a ser la que ya tenía: Variar el xml poniéndole el tipo de datos "a la
> inglesa" para así poder importarlo desde Crystal. La verdad es que,
> después
> de leerme un montón de documentos, no he sido capaz de encontrar una
> solución mejor. Lo siento Miguel Ángel, pero es lo máximo que he
> conseguido
> con tu ayuda.
>
> Hay algo que me sorprende, y es que el problema que tengo yo no lo tenga
> más
> gente. Lo digo porque he estado buscando por ahí y no he encontrado


nada.
> Explicaré exactamente mi caso:
>
> Tengo datos en archivos de COBOL y quiero mostrarlos en un informe de
> Crystal Reports. En vez de hacer un archivo de texto plano separando los
> campos con puntos y comas, pensé: "Será mucho mejor hacerlo con xml, que
> así
> puedo marcar el tipo de datos y operar luego con ellos en Crystal". Pero
> por
> lo visto, a los no anglosajones no se nos tiene en cuenta y los datos
> tienen
> que estar en inglés. Pues nada, a fastidiarse y a tenerlo en cuenta en


el
> momento de generar el archivo.
>
> Un saludo.
>
>


Respuesta Responder a este mensaje
#8 Miguel Angel Campos
07/09/2005 - 19:06 | Informe spam
Pero te vuelvo a insistir que depende mucho de como se esté tratando dicho
fichero en XML.
Si por ejemplo lo lees con las clases de .NET, detectan el encoding que
tiene dicho fichero y actuan en consecuencia. Si lees el fichero mediante
otro procedimiento, ya sea un trozo de código en VB realizado por alguien,
puede que no detecte la codificación y se interprete mal.
Tienes que tener en cuenta que los schemas se utilizan para muchos
propositos, entre ellos para validar las comunicaciones entre WebServices, y
estos servicios no deberían entender de idiomas sino sólo de estandares.
Siempre que puedas deberías utilizar los formatos estandares para
intercambiar ficheros XML, y estos estandares estan bien definidos.
Un Saludo,

Miguel Angel Campos
MCAD.NET

"skar" escribió en el mensaje
news:%
Tambien, pueden tener en cuenta que los documentos xml tienen que tener el
encoding especifico a cada lenguage (gringo UTF8)
otra cosa que se puede hacer, es el usar XML Schema y crear un Datatype
especifico para trabajar con fechas y numeros NO anglosajones:
dia: 22 de Julio de 2005 22/07/2005 versus 07/22/2005

"Miguel Angel Campos" <SPAMmacampos ARRUBA .idesarrollaSPAM.com> wrote in
message news:
No es del todo como crees, si sólo se considerara lo que dicen los
anglosajones no iriamos bien encaminados.
Como te comenté en el otro correo la forma de representar los datos está
perfectamente definida en el estandar y utiliza lo que se llama una


cultura
invariante, es decir, una forma de representar los datos definida
claramente. De todas formas tienes que tener en cuenta que este proceso
se
basa en conversiones de tipos de datos a cadenas y tratamiento de estas
cadenas, si estas transformaciones las haces en un sistema operativo
configurado en Ingles (que se que no es tu caso) las conversiones de
DateTime a string las hará en formato anglosajón, y si el programa que
lee
el fichero XML resultante está instalado en un SO en español intenta
convertir la cadena a DateTime considerando unas reglas.
Si utilizas .NET en tu proyecto puedes modificar este comportamiento,
mediante la utilización de la clase CultureInfo.
Te adjunto un link por si te sirve de algo:
http://www.codeproject.com/dotnet/d...format.asp

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Beren" escribió en el mensaje
news:
> Perdona Patricia, no había visto el mensaje. La verdad es que me ayudó


un
> amigo con un pequeño programa en Visual Basic. Por tanto, supongo que


debe
> ser algo similar a lo que ha enviado skar.
>
> Por cierto, he estado buscando la solución a mi problema y me parece
> que
> va
> a ser la que ya tenía: Variar el xml poniéndole el tipo de datos "a la
> inglesa" para así poder importarlo desde Crystal. La verdad es que,
> después
> de leerme un montón de documentos, no he sido capaz de encontrar una
> solución mejor. Lo siento Miguel Ángel, pero es lo máximo que he
> conseguido
> con tu ayuda.
>
> Hay algo que me sorprende, y es que el problema que tengo yo no lo
> tenga
> más
> gente. Lo digo porque he estado buscando por ahí y no he encontrado


nada.
> Explicaré exactamente mi caso:
>
> Tengo datos en archivos de COBOL y quiero mostrarlos en un informe de
> Crystal Reports. En vez de hacer un archivo de texto plano separando
> los
> campos con puntos y comas, pensé: "Será mucho mejor hacerlo con xml,
> que
> así
> puedo marcar el tipo de datos y operar luego con ellos en Crystal".
> Pero
> por
> lo visto, a los no anglosajones no se nos tiene en cuenta y los datos
> tienen
> que estar en inglés. Pues nada, a fastidiarse y a tenerlo en cuenta en


el
> momento de generar el archivo.
>
> Un saludo.
>
>






Respuesta Responder a este mensaje
#9 Beren
08/09/2005 - 17:21 | Informe spam
Ok Miguel Ángel, entiendo las razones. No obstante, igual que en un schema
puedes marcar los decimales que tiene un tipo float, ¿tan difícil habría
sido poner otro, digamos, parámetro, que marcara en las fechas (por ejemplo)
el idioma en el que están y así, en comunicaciones entre equipos en
diferentes idiomas, entenderse? O un parámetro que dijera que el marcador de
decimales es un punto o una coma. Claro que si lo pienso bien, supongo que
esto complicaría mucho el tema. En fin, patatas en latín, como dice mi
madre. Es lo que hay.

Muchas gracias de todas formas por las aclaraciones. Me han ayudado a
situarme.

Un saludo.

"Miguel Angel Campos" <SPAMmacampos ARRUBA .idesarrollaSPAM.com> escribió en
el mensaje news:
Pero te vuelvo a insistir que depende mucho de como se esté tratando dicho
fichero en XML.
Si por ejemplo lo lees con las clases de .NET, detectan el encoding que
tiene dicho fichero y actuan en consecuencia. Si lees el fichero mediante
otro procedimiento, ya sea un trozo de código en VB realizado por alguien,
puede que no detecte la codificación y se interprete mal.
Tienes que tener en cuenta que los schemas se utilizan para muchos
propositos, entre ellos para validar las comunicaciones entre WebServices,


y
estos servicios no deberían entender de idiomas sino sólo de estandares.
Siempre que puedas deberías utilizar los formatos estandares para
intercambiar ficheros XML, y estos estandares estan bien definidos.
Un Saludo,

Miguel Angel Campos
MCAD.NET

"skar" escribió en el mensaje
news:%
> Tambien, pueden tener en cuenta que los documentos xml tienen que tener


el
> encoding especifico a cada lenguage (gringo UTF8)
> otra cosa que se puede hacer, es el usar XML Schema y crear un Datatype
> especifico para trabajar con fechas y numeros NO anglosajones:
> dia: 22 de Julio de 2005 22/07/2005 versus 07/22/2005
>
> "Miguel Angel Campos" <SPAMmacampos ARRUBA .idesarrollaSPAM.com> wrote


in
> message news:
>> No es del todo como crees, si sólo se considerara lo que dicen los
>> anglosajones no iriamos bien encaminados.
>> Como te comenté en el otro correo la forma de representar los datos


está
>> perfectamente definida en el estandar y utiliza lo que se llama una
> cultura
>> invariante, es decir, una forma de representar los datos definida
>> claramente. De todas formas tienes que tener en cuenta que este proceso
>> se
>> basa en conversiones de tipos de datos a cadenas y tratamiento de estas
>> cadenas, si estas transformaciones las haces en un sistema operativo
>> configurado en Ingles (que se que no es tu caso) las conversiones de
>> DateTime a string las hará en formato anglosajón, y si el programa que
>> lee
>> el fichero XML resultante está instalado en un SO en español intenta
>> convertir la cadena a DateTime considerando unas reglas.
>> Si utilizas .NET en tu proyecto puedes modificar este comportamiento,
>> mediante la utilización de la clase CultureInfo.
>> Te adjunto un link por si te sirve de algo:
>> http://www.codeproject.com/dotnet/d...format.asp
>>
>> Un Saludo,
>>
>> Miguel Angel Campos
>> MCAD.NET
>>
>> "Beren" escribió en el mensaje
>> news:
>> > Perdona Patricia, no había visto el mensaje. La verdad es que me


ayudó
> un
>> > amigo con un pequeño programa en Visual Basic. Por tanto, supongo que
> debe
>> > ser algo similar a lo que ha enviado skar.
>> >
>> > Por cierto, he estado buscando la solución a mi problema y me parece
>> > que
>> > va
>> > a ser la que ya tenía: Variar el xml poniéndole el tipo de datos "a


la
>> > inglesa" para así poder importarlo desde Crystal. La verdad es que,
>> > después
>> > de leerme un montón de documentos, no he sido capaz de encontrar una
>> > solución mejor. Lo siento Miguel Ángel, pero es lo máximo que he
>> > conseguido
>> > con tu ayuda.
>> >
>> > Hay algo que me sorprende, y es que el problema que tengo yo no lo
>> > tenga
>> > más
>> > gente. Lo digo porque he estado buscando por ahí y no he encontrado
> nada.
>> > Explicaré exactamente mi caso:
>> >
>> > Tengo datos en archivos de COBOL y quiero mostrarlos en un informe de
>> > Crystal Reports. En vez de hacer un archivo de texto plano separando
>> > los
>> > campos con puntos y comas, pensé: "Será mucho mejor hacerlo con xml,
>> > que
>> > así
>> > puedo marcar el tipo de datos y operar luego con ellos en Crystal".
>> > Pero
>> > por
>> > lo visto, a los no anglosajones no se nos tiene en cuenta y los datos
>> > tienen
>> > que estar en inglés. Pues nada, a fastidiarse y a tenerlo en cuenta


en
> el
>> > momento de generar el archivo.
>> >
>> > Un saludo.
>> >
>> >
>>
>>
>
>


Respuesta Responder a este mensaje
#10 Miguel Angel Campos
09/09/2005 - 08:56 | Informe spam
No es necesario un parametro, como te comenté antes está definido en el
estandar.
Por ejemplo, el tipo datetime se debe representar de la siguiente forma:
http://www.w3.org/TR/xmlschema-2/#dateTime
en el apartado Lexical representation.

Lo mismo ocurre con todos los tipos basicos, como te vuelvo a comentar, el
problema está en que muchas veces se utilizan librerias que no siguen estos
estandares, sino que por ejemplo interpretan el texto en función de la
configuración regional del usuario activo.

Espero que puedas importar tus datos al final correctamente.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Beren" escribió en el mensaje
news:
Ok Miguel Ángel, entiendo las razones. No obstante, igual que en un schema
puedes marcar los decimales que tiene un tipo float, ¿tan difícil habría
sido poner otro, digamos, parámetro, que marcara en las fechas (por
ejemplo)
el idioma en el que están y así, en comunicaciones entre equipos en
diferentes idiomas, entenderse? O un parámetro que dijera que el marcador
de
decimales es un punto o una coma. Claro que si lo pienso bien, supongo que
esto complicaría mucho el tema. En fin, patatas en latín, como dice mi
madre. Es lo que hay.

Muchas gracias de todas formas por las aclaraciones. Me han ayudado a
situarme.

Un saludo.

"Miguel Angel Campos" <SPAMmacampos ARRUBA .idesarrollaSPAM.com> escribió
en
el mensaje news:
Pero te vuelvo a insistir que depende mucho de como se esté tratando
dicho
fichero en XML.
Si por ejemplo lo lees con las clases de .NET, detectan el encoding que
tiene dicho fichero y actuan en consecuencia. Si lees el fichero mediante
otro procedimiento, ya sea un trozo de código en VB realizado por
alguien,
puede que no detecte la codificación y se interprete mal.
Tienes que tener en cuenta que los schemas se utilizan para muchos
propositos, entre ellos para validar las comunicaciones entre
WebServices,


y
estos servicios no deberían entender de idiomas sino sólo de estandares.
Siempre que puedas deberías utilizar los formatos estandares para
intercambiar ficheros XML, y estos estandares estan bien definidos.
Un Saludo,

Miguel Angel Campos
MCAD.NET

"skar" escribió en el mensaje
news:%
> Tambien, pueden tener en cuenta que los documentos xml tienen que tener


el
> encoding especifico a cada lenguage (gringo UTF8)
> otra cosa que se puede hacer, es el usar XML Schema y crear un Datatype
> especifico para trabajar con fechas y numeros NO anglosajones:
> dia: 22 de Julio de 2005 22/07/2005 versus 07/22/2005
>
> "Miguel Angel Campos" <SPAMmacampos ARRUBA .idesarrollaSPAM.com> wrote


in
> message news:
>> No es del todo como crees, si sólo se considerara lo que dicen los
>> anglosajones no iriamos bien encaminados.
>> Como te comenté en el otro correo la forma de representar los datos


está
>> perfectamente definida en el estandar y utiliza lo que se llama una
> cultura
>> invariante, es decir, una forma de representar los datos definida
>> claramente. De todas formas tienes que tener en cuenta que este
>> proceso
>> se
>> basa en conversiones de tipos de datos a cadenas y tratamiento de
>> estas
>> cadenas, si estas transformaciones las haces en un sistema operativo
>> configurado en Ingles (que se que no es tu caso) las conversiones de
>> DateTime a string las hará en formato anglosajón, y si el programa que
>> lee
>> el fichero XML resultante está instalado en un SO en español intenta
>> convertir la cadena a DateTime considerando unas reglas.
>> Si utilizas .NET en tu proyecto puedes modificar este comportamiento,
>> mediante la utilización de la clase CultureInfo.
>> Te adjunto un link por si te sirve de algo:
>> http://www.codeproject.com/dotnet/d...format.asp
>>
>> Un Saludo,
>>
>> Miguel Angel Campos
>> MCAD.NET
>>
>> "Beren" escribió en el mensaje
>> news:
>> > Perdona Patricia, no había visto el mensaje. La verdad es que me


ayudó
> un
>> > amigo con un pequeño programa en Visual Basic. Por tanto, supongo
>> > que
> debe
>> > ser algo similar a lo que ha enviado skar.
>> >
>> > Por cierto, he estado buscando la solución a mi problema y me parece
>> > que
>> > va
>> > a ser la que ya tenía: Variar el xml poniéndole el tipo de datos "a


la
>> > inglesa" para así poder importarlo desde Crystal. La verdad es que,
>> > después
>> > de leerme un montón de documentos, no he sido capaz de encontrar una
>> > solución mejor. Lo siento Miguel Ángel, pero es lo máximo que he
>> > conseguido
>> > con tu ayuda.
>> >
>> > Hay algo que me sorprende, y es que el problema que tengo yo no lo
>> > tenga
>> > más
>> > gente. Lo digo porque he estado buscando por ahí y no he encontrado
> nada.
>> > Explicaré exactamente mi caso:
>> >
>> > Tengo datos en archivos de COBOL y quiero mostrarlos en un informe
>> > de
>> > Crystal Reports. En vez de hacer un archivo de texto plano separando
>> > los
>> > campos con puntos y comas, pensé: "Será mucho mejor hacerlo con xml,
>> > que
>> > así
>> > puedo marcar el tipo de datos y operar luego con ellos en Crystal".
>> > Pero
>> > por
>> > lo visto, a los no anglosajones no se nos tiene en cuenta y los
>> > datos
>> > tienen
>> > que estar en inglés. Pues nada, a fastidiarse y a tenerlo en cuenta


en
> el
>> > momento de generar el archivo.
>> >
>> > Un saludo.
>> >
>> >
>>
>>
>
>






email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida