>>>>Hi all
>>>>
>>>>Here's an interesting problem I found in an application I inherited.
>>>>
>>>>I strongly advise against single letter aliases in SQL and in VFP from the perspective of readability and maintainability. Be especially careful with M as an alias in VFP SQL.
>>>>
>>>>create table tmpinvoices free (field1 c(10))
>>>>local ltDatetime
>>>>ltDatetime = datetime()
>>>>select m.field1,m.ltDatetime as tdatetime from tmpinvoices m into cursor c_Result
>>>>
>>>>You will get an error that column ltDatetime is not found. OK. So drop the m. from ltDatetime, but now you are slowing your query - admittedly very little, but I don't like doing things half-fast. ;)
>>>>
>>>>I tried to add this to the mdot topic on the wiki, but my changes are not being saved.
>>>
>>>Single letter aliases are OK.
>>
>>How can you say that?
>>
>>Using index tag Deleted to rushmore optimize intermediate result
>>Rushmore optimization level for intermediate result: full
>>Using index tag Recddate to rushmore optimize table d
>>Using index tag Deleted to rushmore optimize table d
>>Rushmore optimization level for table d: full
>>Using index tag Deleted to rushmore optimize table e
>>Rushmore optimization level for table e: full
>>Using index tag Deleted to rushmore optimize table f
>>Rushmore optimization level for table f: full
>>Joining intermediate result and table d using index tag Batchid
>>Joining intermediate result and table e using index tag Id
>>Joining intermediate result and table f using index tag Ccode
>>
>>What is table E? I don't know either. Ya. Very maintainable.
>
>We have very different viewpoints on maintainability. You would surely understand if e was ee:)
>Cetin

I think we agree quite well. A for invoice and B for purchases is ludicrous. Inv for invoice and Pur for purchase is the shortest I'd go for an alias and certainly never M - in VFP.