FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
Error al importar fichero txt
Buenas de nuevo a todos.
Al final he conseguido que delphi XE5 funcione al 100% con todos los componentes instalados. He realizado las migraciones del antiguo código D6 ajustandolo al nuevo XE5. Recientemente he pasado mi máquina Win XP 32 bits a W-7 64 bits. El problema que tengo es que un proceso de importación de un archivo txt se reallizaba correctamente en el formato antiguo y ahora me lanza una excepción sin haber tocado nada del código en esta parte, no se si algun parámetro se debe ajustar a XE5, os pongo el código usado:
y este es el mensaje de error que se produce: First chance exception at $75CEC42D. Exception class EIBInterBaseError with message 'Dynamic SQL Error SQL error code = -303 arithmetic exception, numeric overflow, or string truncation'. Process Rebuts.exe (1932) Si alguien tiene alguna idea del porque me puede pasar pues será muy bienvenida su respuesta. Saludos Josep |
#2
|
||||
|
||||
Hola Jafera
El dato que esta cogiendo del fichero de texto no es un número o el número es demasiado grande, mira a ver en que línea se queda y comprueba el valor. Un saludo.
__________________
Al hacer una consulta SQL, haz que los demás te entiendan y disfruten de ella, será tú reflejo de tú saber. |
#3
|
||||
|
||||
Gracias por la respuesta.
He mirado el fichero txt generado asi como la estructura de la tabla de destino y cuadra todo. No se como hacer para ver el resultado de la linea que es la que me da el error, se debe hacer con un Add Watch? No se estoy un poco (mucho) desorientado ya que este proceso lleva tiempo funcionando correctamente. Saludos Josep |
#4
|
||||
|
||||
El error este se da también cuando el string que quieres importar es demasiado largo para el campo donde debe entrar.
Aparentemente tienes un archivo separado por el caracter ";" Prueba primero importar una sola línea. Si no funciona, seguramente hay un problema en el fichero y no reconoce bien el "corte" de cada columna Si es funciona, prueba a importar 2 líneas. Si no funciona, puede ser que no reconozca los saltos de línea. Si funciona, has una búsqueda dicotómica en el fichero - divide al medio el fichero - importalo - Si no hay error, el error se encuentra en la otra mitad. Si hay error está en la primera mitad. - Vuelve a hacer la búsqueda con la mitad que falla. |
#5
|
||||
|
||||
Gracias por la respuesta.
He importado linea a linea y no me da ningun error. Puede ser esto que comentas que no reconozca el salto de linea? Si es así como puedo hacer que me reconozca el salto, en D6 no daba ningún error y funciono durante mucho tiempo hasta que he realizado la migración a XE5 Saludos Josep Edito: He probado otro proceso que tambien importa otro txt y me da el mismo error, ahora si que creo que no reconoce el salto de linea. Última edición por jafera fecha: 21-05-2014 a las 15:46:09. Razón: Realizada comprobacion |
#6
|
||||
|
||||
Si no me equivoco, este componente también tiene un atributo "RowDelimiter".
Este sería el delimitador de siguiente línea Mira qué es lo que tiene y modifícalo para que sea #13 o #13#10 por ejemplo. |
#7
|
||||
|
||||
Gracias de nuevo.
Yo no veo este atributo por ningun lado, no se si estoy en lo correcto, la generacion del txt lo hago con la consulta sql siguiente:
Estoy perdido. Saludos Josep |
#8
|
||||
|
||||
Puede ser que algún valor de los que exportas tenga un ; dentro y al importarlo lo separe en dos y todo se mueva...
Imagina que el valor de un campo tipo string contenga el caracter que utilizas para separar campos: NOMBRE = 'JUAN PEREZ' DIRECCION = 'AV. PRINCIPAL NRO. 123; PISO 3' <-- Hay un ; en medio. IMPORTE = 1234.56 si exportas esto como NOMBRE;DIRECCION;IMPORTE tendrás : 'JUAN PEREZ;AV. PRINCIPAL NRO. 123; PISO 3;1234,56' Al separarlos obtendrás: NOMBRE = 'JUAN PEREZ' DIRECCION = 'AV. PRINCIPAL NRO. 123' IMPORTE = PISO 3 <-- Esto no es un valor numerico Otra cosa que puede estar molestando en la importación es la conversión de Float a String. En España se utiliza la "," como separador decimal. En Norteamérica se utiliza el "." La convertir mediante FloatToStr utiliza el separador decimal que el ordenador tiene definido y esto puede traer problemas si la importación espera valores separados por "." decimal |
#9
|
||||
|
||||
Revisado de nuevo y no hay ningun ";" dentro de ningun campo.
Lo mas extraño es que tal y como he comentado antes en D6 funcionaba bien y en XE5 no. Cuando llegue a casa tengo una máquina con XP 32 bits y probaré si allí lo importa, luego comentaré el resultado Gracias a todos Josep |
#10
|
||||
|
||||
Probado en una máquina XP 32 bits y falla igual, da el mismo error.
Existe alguna forma d visualizar linea a linea lo que voy importando para sabere n que momento peta? Gracias Josep |
#11
|
||||
|
||||
Hola a todos.
Más investigaciones, ejecutando el código en DXE5, falla siempre incluso si le pongo una sola linea me dice que fichero importado, (con lo que creia que lo habia solucionado), pero no importa nada no añade ningun registro a la tabla; si pongo más lineas pues sql error -303 etc, etc.. Si introduzco a mano los datos del txt directamente desde IBExpert en la tabla, me lo coge perfectamente, con lo cual deduxco que no es un problema del formato del txt, aunque algo esta temblando por ahí y no lo consigo aislar. Si ejecuto el código, que es exactamente igual (he revisado linea a linea), en D6 me importa el fichero sin más. He revisado el tema del decimal separator y está establecido en el '.' (punto), en la configuración de W7 tambien está establecido el punto. No se que más mirar, estoy más perdido que una cabra en un garaje. Gracias y saludos Josep |
#12
|
||||
|
||||
Revisa que el fichero generado también tenga como separador decimal el '.' (punto).
Si lo generas en un ordenador y lo lees en otro, esto podría traerte esa parte modificada. El formato de la fecha también es importante. Dependiendo del separador, el orden de los elementos es diferente para Firebird (mm/dd/aaaa dd-mm-aaaa aaaa.mm.dd) Verifica que el tipo de campo acepte el valor que le envías: SMALLINT 0..65535 INTEGER 0..muuuucho VARCHAR(x) x caracteres CHAR(x) x caracteres Lo dicho anteriormente: Si hay comillas o comillas simples, puede que eso estropee el formato |
#13
|
||||
|
||||
Hola de nuevo.
Sigo dándole vueltas al asunto. He probado toda clase de valores en los campos y nada de nada, he probado a guardar el txt como ansi, como unicode, como utf-8 y tampoco. He probado con otro proceso de importación con otro fichero txt completamente distinto dentro del mismo programa y me da el mismo error. He quitado el componente que hace la importación (IBSQL), lo he vuelto a soltar dentro del form por si fuera un problema de version actualizada y tampoco funciona. Estoy semi desesperado, en un XP a 32 bits con D6 funciona bien pero en un W7 a 64 bits con XE5 nada de nada. Como comenté en un mensaje anterior el código de una versión a la otra es exactamente el mismo. Porqué narices la compilación D6 funciona de fábula y la XE5 no? Tendré que cambiar los componentes de acceso a datos? Gracias por vuestro tiempo. Saludos Josep |
#14
|
||||
|
||||
¿Pero por qué no miras en qué linea se detiene?
Tienes muchas formas de hacerlo, por ejemplo, en el bucle puedes mostrar el valor de uno de los campos, código, nombre, etc. que te sirva para reconocer la línea. También puedes escribir un contador y luego miras en el fichero de texto la línea a la que corresponde. Etc... |
#15
|
||||
|
||||
Gracias Antonio.
El problema es que no me importa ni una sola linea, eso es lo que me da quebraderos de cabeza. Tal como comenté en un post anterior si cojo el valor de los campos y los meto a mano en la tabla mediante IBExpert no me da ningun error. Si pongo una sola linea en el txt me dice que la ha importado pero en la tabla no se refleja nada. Esto es lo que me pasa basicamente Saludos Josep |
#16
|
||||
|
||||
Ahora mismo no recuerdo, pero ¿esto es correcto?
Quiero decir que si ¿writeln admite valores separados por comas? |
#17
|
||||
|
||||
Hola de nuevo.
El separador es el punto y coma. Por lo menos defino el en la importación. Pero como ya comenté este código en D6 lleva cuatro años funcionando perfectamente en este proceso y algo similar en otros procesos Josep |
#18
|
||||
|
||||
Por qué no pruebas a escribir cualquier cosa, para empezar. Por ejemplo,
Y a partir de ahí vas viendo, según el resultado. |
#19
|
||||
|
||||
He seguido haciendo pruebas.
He creado un fichero a mano con el orden de los campos dejando solo los campos enteros y los alfanumericos en blanco y el resultado es la imagen adjunta. Creo que por lo que deduzco me interpreta toda la linea como una cadena. No se que mas mirar. Saludos Josep |
#20
|
||||
|
||||
Todo indica que está asumiendo que todo es una misma columna.
Te propongo una prueba mas: Genera el fichero con la función TIBOutputDelimitedFile De esta manera te asegurarías de que quien escribe el fichero y quien lo lee es el "mismo componente". Una vez lo hayas exportado, compara los fichero para ver dónde está la diferencia. Quizás espera un espacio entre campos o necesita que los strings estén entre comillas o alguna cosa de esas. Ya nos informarás de si esto ha servido... |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
DELPHI6 Importar fichero codificado UTF-8 a Dbase | Jose Manuel | Varios | 0 | 16-05-2011 18:46:14 |
Importar fichero XML | cincosoft | OOP | 1 | 08-02-2009 10:29:58 |
Importar fichero .dat desde cobol | julian_ch | Varios | 0 | 08-08-2005 17:43:17 |
Error al importar dll | mguixot | Varios | 2 | 08-07-2005 15:47:26 |
importar fichero consumo telefonica | tonid | Varios | 3 | 11-09-2003 09:49:28 |
|