Hi, I found this post in the peg archive and we are having the same issue. Any idea how to fix this? > Does anyone know how a blank line gets in a file. > I create a file with price data in it. > It is a comma delimited file. > We run the report at night in our batch queue. > The next morning we would email the file out to it's recipients. > I added code to the program to email out the report automatically using > smtpmail.p > I got it to work and the file is getting emailed out, but the recipient > says there is a blank line at the end of the file and he has to take it > out manually. > That blank line must of never been in there before because they did not > complain about it. > I did not change the code that creates the file. > After the report close line I added the code for smtpmail.p > Any ideas?
> Does anyone know how a blank line gets in a file
How you create a file?
Windows or Unix?
Empty line adds 1-2 bytes to the file's size. You can check its size before OUTPUT CLOSE:
DEFINE VARIABLE vOutFile AS CHARACTER NO-UNDO INITIAL "1.txt".
DEFINE VARIABLE vString AS CHARACTER NO-UNDO.
ASSIGN vString = FILL("x", 4).
OUTPUT TO VALUE(vOutFile).
PUT UNFORMATTED vString SKIP.
FILE-INFO:FILE-NAME = vOutFile.
MESSAGE "After PUT:" FILE-INFO:FILE-SIZE VIEW-AS ALERT-BOX.
PUT CONTROL NULL(0).
FILE-INFO:FILE-NAME = vOutFile.
MESSAGE "After PUT CONTROL:" FILE-INFO:FILE-SIZE VIEW-AS ALERT-BOX.
OUTPUT CLOSE.
FILE-INFO:FILE-NAME = vOutFile.
MESSAGE "After OUTPUT CLOSE:" FILE-INFO:FILE-SIZE VIEW-AS ALERT-BOX.
The file is created on Linux. At the end of each line there is a LF.
When the file is received there is a addtional CRLF at the end.
On top the file after it is sent using smtpmail.p.
On the bottom the file before sending it (without the CRLF at the end).
Can you count the number of characters?
Some mail servers will auto insert CRLF after the 78th chars and others do it after the 990th character for a very long character line. I don't think LF is a valid line terminator for email, so the server might be thinking that you have one long line.
I would try setting the filetype of the attachment to binary so that it gets base64 encoded before sending. That should stop unexpected manipulations.