As I see it, you are absolutely right here. I do not see any real advantage in using a variable name assigned the alias instead of the alias itself, unless the routine must act upon varying alias names. The disadvantage is less readable code indeed.
>>We have several routines/quirks that are prsent in our company coding standards.
>>
>>
>>BAsically all tables are aliased into variable so they can be changed in one place in each method/function.
>>
>>All of our scans are run around variables containing alias names:
>>
>>lcAlias = 'Table'
>>...
>>...
>>...SELECT &lcAlias
>
>However, if 'Table' was Customer.DBF the code that refers to lcAlias now becomes less readable. You could get the very same effect without the need for any evaluation or macrosubstitution using the USE command itself. If the table name changed, you would just change the USE line. CustomerAlias would be an unlikely change as the method should be dealing with Customers - in this example.
>
>USE Table ALIAS CustomerAlias
>select CustomerAlias
>scan
>
>If the routine was more generic, such as it was updating a table with some values you could...
>
>USE Table alias TargetTable
>SELECT TargetTable
Groet,
Peter de Valença
Constructive frustration is the breeding ground of genius.
If there’s no willingness to moderate for the sake of good debate, then I have no willingness to debate at all.
Let's develop superb standards that will end the holy wars.
"There are three types of people: Alphas and Betas", said the beta decisively.
If you find this message rude or offensive or stupid, please take a step away from the keyboard and try to think calmly about an eventual a possible alternative explanation of my message.
