David,

Thanks for your insight. My thoughts...


Two lines. You forgot the LOCAL declaration which is just as important.
Every procedure using local variables should have a LOCAL statment. It's a forgone
conculsion. And it would certainly define other variables as well. So it's already there.

But honestly, you could get away with not using the LOCAL. The variable will still
drop out of scope. Not appropriate, IMHO, but it would work.

And there's the line of code somewhere that puts SetCommand into the current classlib path.
Thats done at the app level. Not relevent in the method using the class.

Or if you prefer newobject() and now you've littered your code with classlib names which may hinder future changes to your classlib structure...
I use CREATEOBJECT() in most cases. And do you consider it 'littering' when you
instantiate other classes used in your app? And what if other class names change?
Seems to me the 3 lines of code needed to do it the 'standard' in a method is more
dirty than the one line class instantiation.

Then there's the object instantiation/destruct time added to at least consider. So it's not quite as simple an issue.
This is a very light class. Not going to take forever to create.

Seems to me your coming up with fuzzy reasons to knock this method. If it doesn't work
for you, so be it. But I get cleaner code with one line instead of the multiple lines
needed to Set & Reset SET statements.

I have a procedure in my app class that sets them all together. I pass in the data
session Id and call it from Form.Load(), but in some individual cases where you
simply need to set one then reset it, this make alot of sense.