David,

Looking closely into output file my colleague noticed, that some lines were 'eatten'. It was exactly 31th line. So, she played with _ASCIIROWS settings and empirically determine the magic number for this particular report - 28!!!! Isn't it funny? :)))

Hopefully, this bug would be fixed in VFP7.0

>Nadya,
>
>>Sorry, if this question was already asked bunch of times. Colleague of mine showed me today a problem with the report, she created.
>
>You may be able to get around the problem with double-spaced lines by changing the value of _ASCIIROWS. It is not very intuitive, and does not make any kind of logical sense, so don't bother figuring out WHY this works the way it does -- it's just a buggy situation.
>
>Here is Microsoft's recommended solution from the Knowledgebase article Q172851:
>
>Issue the following command:
>
>_ASCIIROWS=30
>
>Then print the report to the file using the ASCII clause and it does not place the extra CR+LF into the text file output.
>
>NOTE: The default for _ASCIIROWS = 63.