>>>Hi,
>>>
>>>I have a function that uses XFRX to convert a report to a PDF format.
>>>
>>>The report to be converted to PDF has multiple bands. XFRX handle it fine but the cursor names that are used for the bands have to be in scope inside the MyXFRX() function. And I used local variable. For example:
>>>
>>>local Band1Cursor, Band2Cursor
>>>Band1Cursor = sys(2015)
>>>Band2Cursor = sys(2015)
>>>
>>>
>>>With the above scenario the MyXFRX function gives an error that variable Band1Cursor does not exist.
>>>
>>>The solution - so far - is to either make the variables Private or hard coded. That is, do not use variables but instead use names like CUR_Band1, CUR_band2
>>>
>>>Which approach would be a better practice?
>>>
>>>TIA
>>
>>Variables declared as LOCAL are only visible in the procedure/function context where they are declared.
>>Variables declared as PRIVATE are available in the procedure/function context where they are created as well as in context of called procedure/function. When a PRIVATE is used, variables listed In the PRIVATE statement that already exist as PUBLIC or as PRIVATE within the calling procedure/function will be "hidden" and assignment to the variable will create new instance at that level where the assignment takes place. Variables are implicitly declared as PRIVATE.
>
>Thank you. I believe I understand how PRIVATE variables work. But I am wondering if instead of PRIVATE variable I would be better using a hard-coded cursor names. Because hard-coded cursor names visible in the called procedure as well. Or, maybe, this is just six or half dozen.
(shrug) it all depends on usage case. If you hard-code cursor names it may work well for certain context, but not for others. Using fixed variable name might make it more adaptable -- though again you're still hardcoding a name. Perhaps passing of the names as parameters might work better?