Sylvan,

A blank sheet of paper is characteristic of there being no records which match the report criteria. Printing only one record when you expect several is typical of reports run off related tables when the wrong table is selected or SET SKIP is not used.

I'm curious about your BROWSE vice BROWSE NOWAIT.

I would run with trace and debugging windows with breakpoints when the selected work area changes. I would watch datasessions very carefully when printing the report from different parts of your app.

You mention a CURSOR with primary keys of the records you want. This leads me to believe you are setting a relation from this into another table.

I have had my best luck with SELECTing all of the data I need for the report into one CURSOR and running the report from that. Running off related tables always left me with errors of one sort or another.


>Hi all!
>
>This problem has me stumped for a few weeks. I have 3 reports that are called from different parts in the application. All 3 reports works as expected.
>
>Now I also have a somewhat complicated form that can also call those 3 reports. Like the other places in the application where those reports are called, I create a cursor containing the primary keys of the records I want to print, and call a PRG (the same PRG than in the other places in the app). When called from that form, reports won't print correctly: often, only one record is printed, other times it prints just a blank page.
>
>When it goes weird is that if I put a browse just before printing, everything prints fine. Issuing a BROWSE NOWAIT does not help, however.
>
>I would like to avoid redoing that form since it is complicated. Has anyone ever seen something like this? I'm using VFP6 SP3.
>
>Going crazy! :)