>>I have a function MyReport() where the local variables were declared and the value of SYS(2015) assigned. Then these cursors were populated.
>>Then, in order, to convert the report to a PDF, another function MyXfrx() was called. Inside the function MyXfrx() the report was being changed to PDF.
>>The problem, I realized later was that in the report I was using the names of the cursors. E.g.
>>

>>evaluate( cursorBand1 + ".myfield" )
>>

>>and it would cause a run-time error.
>>I changed the variables (in MyReport()) to PRIVATE and it got around the problem.
>>I am not comfortable with a PRIVATE. So, when I have time, I will change the variables to hard-coded cursors.
>
>Actually, that kind of thing is the only use for Private that I am comfortable with - when you pass down a procedure/function call something that contains a dependency on a variable, then that variable needs to be in scope where it's used. In my case, it's various sql command strings containing ?parameters, which I don't run in the same procedure where the parameters are assigned, but pass them to a specialized object (call it SqlHandler or something such). That object needs to see these parameters or else the SQLexec() will break when parser tries to replace them with values. So private they are, and I often write a comment explaining why they are private.
>
>As long as you're disciplined with this and declaring private is an exception used when really needed, you'll be fine.

I agree and instinctively (because I am still a newbie to VFP and programming :) realize that this use of PRIVATE is ok.
But I am a perfectionist (bad quality for an entrepreneur) and will probably change my code anyway.

As far as your case, using SQLexec(), I agree. Although I have a function for the SQLExec() and pass parameters as variables. And I know that I am in danger of SQL injection attack. But I have learned to live with this threat.
Thank you.