>>Rich,
>>
>>>That being said, maybe it's better to check them all since a couple of the modules might really need the local versions.
>>
>>I do not understand why you need to use private parameters in the first place, but now that you said you are modifying existing code, that was working with local parameters got me really confused for local parameters and even local variables are much better and you should scarcely use private variables, imo.
>>
The current code jumps through hoops to bury the values into an SQL statement. For example

lcSQL = lcSQL + [ WHERE myfield = '] + tcParm + [']

and equivalent stuff for date and numeric fields. I wanted to convert to

lcSQL = lcSQL + [ WHERE myfield = ?tcParm]

which, at least in my opinion, is cleaner and more readable. Unfortunately, tcParm goes out of scope because the parameter is local.

As I mentioned to Naomi, the are several ways around this, but they involve changing each module. At first I thought that if there were some global setting that would change the default parameter scope to PRIVATE, that would simplify matters.

In writing this message I realized that I will have to rewrite all those modules anyway to use the ?myVar syntax. It wouldn't be that much more difficult to rework the code so that I retain the Local parameters, which makes the original question no longer relevant.

Thanks to all for responding. At least I got a chance to work out some more details of the problem.




>>Oh, I forgot to say that I do not know of any way to accomplish what you want
>
>Exactly! <g> I was trying to make the same point, but didn't explain it so well.