>>
>>Reports are scoped to have access to any variables that the calling program or form or class had at the time the report was run. For example .. if you have a PRG with this code:
>>
>>LOCAl lnValue
>>lnValue = 10
>>REPORT FORM MyReport TO PRINTER PROMPT PREVIEW
>>
>>You could put lnValue as the expression in a field on the report it will print the number 10.
>>
>>That said ... please explain a little bit more of what you are trying to accomplish. There might be a better way to do it.
>
>What I was trying to do is what Dragan calls "intelligent" report. Here is a brief description.
>
>I have a report in my vertical market application. The report cursor is created in a form, once user enters his/her criteria for the report. The base for the report is a cursor created from a table (kind of simplified as in example of P.O. Header).
>
>Then comes one customer who wants to include in the report records from the table related to the report base table (e.g. P.O. Header -> P.O. Lines). So instead of changing the base SQL select for the report cursor (to include line items and then group) I wanted the report to "get" related data on-the-fly. So that for every line in the report there would be a call to a function that would get the record(s) from the related table. I have actually done it already in one other report and it works. But there I was retrieving just one field from the related table. Now I need to retrieve more than one field. This is where the idea of calling a function and storing some values in report variables came to mind.
>
>I really don't want to (and don't have time) to change the report SQL Select engine. So I either will have to come up with a way to create an intelligent report or tell the customer to wait when I have more time.
>
>Thank you for your input.

You could put code in the OpenTables method of the report to create a second cursor with all the extra fields you need. Set a relation to the main cursor so that the new cursor is always on the appropriate record. In your report, you can just reference the data in the new cursor. Here's an example of the code in OpenTables.

NODEFAULT && This stops the native behavior of opening tables after all this code is processed.
SELECT **** FROM *** INTO CURSOR tmpExtraStuff
INDEX ON *** TAG *** 
DODEFAULT() && This forces the tables to be opened in the DE to be opened now 
SELECT This.InitialSelectedAlias
SET RELATION TO ** IN tmpExtraStuff

If you don't open tables in the DE, you could do something like this:

lcAlias = ALIAS() && Get the current alias
NODEFAULT && This stops the native behavior of opening tables after all this code is processed.
SELECT **** FROM *** INTO CURSOR tmpExtraStuff
INDEX ON *** TAG *** 
DODEFAULT() && This forces the tables to be opened in the DE to be opened now 
SELECT (m.lcAlias)
SET RELATION TO ** IN tmpExtraStuff

Now in your report add objects with expressions such as tmpExtraStuff.Field1, tmpExtraStuff.Field2, etc.