>>>>>There is one important problem in this code sample - the OrderDate is not prefixed with the alias. Without that we would need to check which table this column belongs to.
>>>>>My rule of thumb - prefix every column with an alias name when the query involves more than 1 table.
>>>>
>>>>I don't disagree with the rule of thumb, especially with several tables. But with 2 tables (a business entity master and a child table of orders), any question about the lineage of OrderDate is more likely a problem with the person in the chair. :)
>>>>
>>>
>>>The rule is the rule - and I always follow it.
>>
>>My rule says that all fields within a database have a unique name by having a three letter prefix and an underscore for every field in a table, therefore not needing to prefix any field with an alias. As a bonus in the result of the query you always know where the field comes from.
>>
>>Walter,
>
>Walter, I'm not trying to play word police, but what you're describing is a practice/methodology, not a rule.

As is the "rule" of thumb described above.

>(Actually, what you described is kind of interesting, hadn't thought of that approach)

>I rather doubt that if I came along and created a table in your database, it would fire off validation errors....unless you tell me you've wrapped a rule-based DDL trigger engine around your database...then it might be a rule.

:)

Walter,