>>>Hi all !
>>>I use command report to file ascii. I seems to ignore system variable
>>>_asciicols.
>>>When I set _asciicols = 155 it produce a file with 129 ,
>>>when I set _asciicols = 200 it produce a file with 181 columns and in result some characters and digit disapears in the file because there are no place for them in the line.
>>>Can anybody had similar experience or can anybody explain such behavior or have anybody workaround for this.
>>>Thanks in advance !
>>
>>This is the reason I void TO ASCII at all costs. It is just too unpredictable. To complicate things even more, you massage your field placement to get it working just right, and a different printer will break it. Since VFP uses the current printer to render the text file, results vary from printer to printer.
>
>
>My first contact with report to ascii was quite good. When it have place to
>put strings into text line result is not bad. Problem is that it seems not exactly keepeng _asciicols. But I will try to achieve an effect by giving a user possibility to change _asciicols and proposing a standard printer driver (EPSON FX 80 for example). I don't want ( I can't ) leave dot printers users behind and I don't want create duplicate reports, one for DOS and another for WINDOWS because in our appliactions is above fifty different reports.
>Thanks to all for your input.
>Greetings

It takes time, but you could experiment with different values of _ASCIICOLS for each report, and set the value before running each report. A default of 110 or so could be put in your program's startup, and used for most of the reports. You could disable whatever control allows TO FILE ASCII for certain reports where it doesn't work at all.

I also use similar functions in Access 97. They work best when the report controls are on single lines (word-processor style), are well-separated from each other (no overlap) and are more than big enough to contain their text.