Re: Avoiding New Fields Causing Ambiguity Errors
Date: 9 May 2002 13:02:31 -0700
rhairgroveNoSpam_at_Pleasebigfoot.com (Bob Hairgrove) wrote in message news:<3cd827a2.773452_at_news.ch.kpnqwest.net>...
> On 7 May 2002 11:35:49 -0700, topmind_at_technologist.com (Topmind)
> >Title: Avoiding New Fields Causing Ambiguity Errors
> >Is there any "best practices" standards that deal with this issue?
> Yes ... always alias the table names in any query which involves more
> than two tables and include the alias in the SELECT list for each
> column (or else include the table name verbatim). Don't leave this to
Name every column explicitly? That would make for *huge* query statements, and is not as change-friendly since for each new field you use in the application, you have to remember to include it in the query.
It would be nice if only the conflicting names could be aliased, but some DB's don't like this, plus you still have to change the field references in the application(s), which is what we want to avoid.
Perhaps if the result set gave priority to any explicit aliases, then you could do something like:
SELECT ....., B.foo AS foo FROM zog A, trog B .....
Any reference to "foo" in the result set would then be to "trog.foo".
That would be nice.
> Bob Hairgrove
Thanks for the feedback,
-T- Received on Thu May 09 2002 - 22:02:31 CEST