>>>I didn't say it's necessary. I said it's a good practice. Doing this way you don't have to worry if some cursor 'tmpMyfavouritename' was left open (or is really need to be kept open) in some place and you try to use it now.
>>
>>That is simply your opinion. It is better to
>>
>>USE SOMETABLE ALIAS knownalias
>>
>>than it is to
>>
>>lcAlias = someudf()
>>use sometable alias &lcAlias
>>
>>as you will have to constantly use macrosubbing or eval to use those aliases. This reduces the readability of the code and reduces performance.
>
>I was using this technique (as required by the in-house framework), and it had a few good sides. First, the method which generates cursor names also keeps track of them, and in .destroy() just closes any open ones. Second, the names are guaranteed to be unique, so in case I need to instantiate more than one object which creates its own cursor, there will be no accidental stepping over toes/cursors of any other object.
>
>The downside is that you don't actually know what the alias is, so you can't easily use it in alias.field construct, but there are workarounds:
>
>
uValue=eval(forceext(lcAlias, "fieldname"))
>replace fieldname with uValue2 in (lcAlias)
>
>And, uh, I'd never use a macro. Name expressions work for aliases.
>
>Maybe Edward has done some benchmarking, so maybe &alias may be faster than (alias) - I just prefer using name expressions wherever possible, simply because they told us so in FP2.0 (or was it 1.0?).
I don't use macros too, except in Select-SQL where it's a necessity.
Edward Pikman
Independent Consultant