For any data you need to pass to the report, you can just as well use private variables. Those will get destroyed as soon as your program finishes. (Unlike local variables, private variables are also visible in any program called from the program they are declared in; this will include the report.) I sometimes use private variables for variable header information.

On the other hand, you really have too many variables. See if the report variables are helpful for your purposes. Report variables are defined within the report itself (from the Report menu), and can assist you in summing or averaging information, amongst others.

Another way to pass information to the report is through a cursor. You can add additional fields to the cursor underlying the report, or you could have an additional cursor for fixed data (the same information throughout the report). A cursor is a temporary table; by its very nature, it gets destroyed as soon as you exit the form where you define it. Of course, I am assuming: (1) That you use a form for accepting user options for the report; (2) that the form uses a private DataSession - really the only reasonable way to work, once private DataSessions became available.

None of the above is new to VFP 9 - in fact, I am talking about technology which was already available in VFP 3.

HTH,

Hilmar.

>Just wondering if there isn't a safer/more elegant way to do this, now that we're all the way up to VFP 9...
>
>I have a program that creates a couple dozen variables for a report. I declare the variables public, and then the report uses them when printing. So I start with something like:
>
>

>PUBLIC iVolSvcCount, iVolSvcHrs, iVolOthCount, iVolOthHrs, iVolCountTotal
>PUBLIC iVolActivity, iVolBoard, iVolFundraising, iVolLPPrep,  iVolOffice, iVolOther
>PUBLIC iVolOutReach, iVolPlanning, iVolTraining, iVolTravel
>PUBLIC iVolCtActivity, iVolCtBoard, iVolCtFundraising, iVolCtLPPrep,  iVolCtOffice, iVolCtOther
>PUBLIC iVolCtOutReach, iVolCtPlanning, iVolCtTraining, iVolCtTravel
>PUBLIC iVolWash, iVolOrange, iVolLamoille
>

>
>And then I do a bunch of SQL queries, and dump the results into the variables, like:
>
>

>SELECT voltime.person_id,SUM(voltime.HOURS)AS TOTAL FROM voltime,curVol;
>	WHERE voltime.person_id=curVol.person_id;
>	AND (voltime.DATE BETWEEN THISFORM.txtStartDate.dvalue AND THISFORM.txtEndDate.dvalue);
>	AND voltime.person_id NOT IN (SELECT person.person_id FROM person WHERE staff);
>	GROUP BY voltime.person_id;
>	INTO CURSOR curTemp
>
>SUM curTemp.TOTAL TO iVolOthHrs
>

>
>..and then use iVolOthHrs in the report.
>
>I'm sure that I should probably be clearing them all after running the program...OTOH there must be a way to refactor this mess?
>
>The program code sits in two places, (at the moment...) in the Click event of a form which gathers a bunch of parameters for running the report, and in a series of form methods which do some auxiliary processing. Because I have to pass reference the variables within the report, and between the various locations of in the form...at the time it just seemed to make sense to keep the variables public. (I mean...it Just Works....right?) Also this whole thing is a holdover from about VFP 3.