>>>>>Hi,
>>>>>
>>>>>I am having a crazy problem that I can't seem to understand. In a command button click method I create a cursor. I add one record to the cursor. One of the fields of the cursor is type M. This field is on a report set to Stretch with Overflow. When I set a string into this field of about 1340 characters or more the report prints many, many pages (I usually stop after about 30-40). If I set the string of less than 1340 (approx) the report prints on one page. What I don't understand is why it goes from 1 page to many, many. Logically I could see it going from 1 to 2 pages but why to so many?
>>>>
>>>>Does the string have ASCII form feed character(s) ( CHR( 12 ) ) near the end?
>>>>
>>>>Do you get the same result if you print to a different printer e.g. a PDF printer driver like PrimoPDF?
>>>
>>>I don't know about chr(12) but I will check it. But when I tested it with just populating a string with REPL('1', 1340) so that string didn't have any chr(12) for sure and I still had a problem. Strange.
>>>
>>>And I only print to a PDF printer driver since I don't have a printer at home.
>>
>>Another thing to try would be a printer driver for an actual printer (e.g. HP LaserJet model), with its output set to FILE:.
>>
>>Is SET REPORTBEHAVIOR 80 or 90?
>>
>>What else do you have on the report? 1,340 characters is quite a lot, maybe your memo is trying to stretch beyond the bottom of the page.
>>
>>I don't use them often, but I believe there are some report options like "Repeat group headers on subsequent pages". If something like that was set, and your memo field was in a group header, you could conceivably get some sort of infinite loop situation like that.
>
>Thank you very much again. This was it; the fact that I had the entire report in the header. Originally this report was supposed to print only a couple of lines (it is actually a copy of another very similar report). And today I added stuff to this report; hence the long string. And it must have been causing what you said "loop situation." I moved the field to the Details band and works fine now.

Glad you found it. What you were seeing makes a certain kind of sense:

- The full header band is supposed to be printed at the top of each page
- Start the report: Page 1. Engine tries to print header band
- Header band too big for one page - continue to Page 2
- Page 2 started: print the header band, starting from the beginning
- Header band too big, proceed to Page 3
- ad infinitum

I don't know how the report engine handles that, but if header creation calls get nested because none ever finish, you might eventually see a failure due to too many nesting levels (VFP9 limit is 384). You might run out of GDI or other system resources before that, though.