FoxPro/Visual FoxPro - Al exportar registros de un curso a un archivo txt me hace una ultima linea en blanco

Buenas...

Tengo un inconveniente con la generación de archivo de texto con datos - registros de un cursor.. sin problemas hago esa exportación.. solo que después de abrir el archivo generado veo que crea una ultima linea en blanco y no quiero que haga eso.. agradecería mucho si pueden ayudarme.

cNro_Coop=""
VarPlatxt="C:\Informes\001"+cNro_Coop+vFecPre+".txt"

SELECT CurDatos
GO TOP
COPY TO (VarPlatxt) DELIMITED WITH TAB WITH ""

este el código que utilizo para hacer la exportación de datos al archivo de texto.

Lo que ocurre es que ese método genera archivos cuyas líneas terminan con CHR(13) + CHR(10), por lo que cualquier editor de texto te mostrará una línea adicional. Eso no sucede si lo ves con un editor hexadecimal (no hay CHR(32) después del avance de línea y fin de línea.
Los podrías sacar, pero es probable que el destino omita la última línea.
No sé cual sería el destino de ese archivo.

Tengo que enviar ese archivo de texto al banco via web para actualizar datos, el sistema que recibe esos datos me pasa el formato que debo seguir para poner los datos en un orden especifico y el archivo debe ser .txt.
Mi solucion es generar el archivo y antes de enviar al banco edito el arhivo.txt con bloc de notas, borro la ultima linea en blanco, guardo y envio al banco, no es la gran cosa pero el encargado del envio de datos en la empresa en donde trabajo me pidio para poder sacar esa linea en blanco para no tener que hacer todas las veces ese proceso de editar el archivo antes de enviar.

Lo que tenés que tener en cuenta es si cada línea debe terminar con CHR(13)+CHR(10) (0D+0A) o con otro formato.
El caracter chr(10) marca un fin de línea (EOL) y el CHR(13) manda un "retorno de carro".
Si lo que pide el banco tiene este formato, no tenés que quitarle nada. De lo contrario, es posible que te rechaze el archivo por error de formato, o bien que omita la última línea. Y también que no se queje, porque eso depende de cómo está armado el parser.

Mi sistema genera archivos para Afip, Retenciones y Percepciones Caba, Retenciones y Percepciones Buenos Aires, retenciones y percepciones Santa Fe, lista de pago de sueldos para Banco Santander Río, etc. La única diferencia es que todos los nombrados son de espaciado fijo, o sea van por Standard Data File, y tienen que tener retorno de carro y fin de línea. Nunca modifico esos archivos.

Insisto con lo mismo: lo que vez en un editor de texto no es exactamente lo que está en el archivo. Fijate que los caracteres CHR(13) Y CHR(10), son no editables en todos los procesadores. En lugar de mostrarse generan una conducta determinada. Por ejemplo, te permite ver el texto separado y saber cómo agregar caracteres al final del archivo.

Si lo ves con un editor de hexdecimal (por ejemplo XVI32, que es gratuito) vas a ver que no tiene ninguna línea agregada. Por el contrario, los caracteres 0D Y 0A son lo último que hay. No verás los hexadecimal "00" ni tampoco espacios (hex "20")

Fijate en la imagen adjunta. El archivo de texto se generó con un comando COPY exactamente como el que indicas. Los campos están separados por Hex 09 (chr(9)). Si lo mirás con un editor de texto, de mostrara una línea en blanco al final. Pero no hay nada alli.

De todos modos, si querés sacar esa línea en blanco, seguí lo que indiqué antes, acá lo repito

• hexadec_img.zip(435,2 KB)

Buenas Diego

Como te dice Fidel Jose es algo normal. Mi alternativa es mucho más laboriosa, pero consistiría en que hicieras el archivo a mano, es decir, montas tu cadena de texto con el texto que quieres enviar y después sí que lo metes en el archivo .txt que comentas. En principio, así no tendrías más caracteres de los que le metas, pero claro son muchas más líneas de código. Tienes que ver que te compensa más tener la línea en blanco o no tenerla, pero tener que escribir una porrada de líneas de código a mayores.

Un saludo

Esta es una forma de quitar los caracteres 0D y 0A (CHR(13) + CHR(10) del final del archivo.


Pero insisto en que puede no ser una buena idea, porque depende del parser de lectura.