Re: Avoiding New Fields Causing Ambiguity Errors

From: Topmind <topmind_at_technologist.com>
Date: 15 May 2002 12:58:51 -0700
Message-ID: <4e705869.0205151158.402316b1_at_posting.google.com>


tonkuma_at_jp.ibm.com (Tokunaga T.) wrote in message news:<8156d9ae.0205140433.45dd1d4c_at_posting.google.com>...
> >
> > It seems that some database engines don't let one use
> > alias columns within WHERE clauses for some odd
> > reason. I often get "invalid column" when I try to do
> > this. Thus, I have to resort to the "native" name
> > with a table/entity qualifier in WHERE clauses.
> > This works, but makes generated
> > criteria code more difficult to manage because
> > the result set column name differs from the
> > criteria column name.
>
> This is not the odd reason, in my opinion.
> The sequence of evaluation of each clause in a select statement is
> defined by SQL Standards, and perhaps implemented strictly in some
> DBMSs.
> Without these defined sequence, the result of a query may be
> unpredictable or cause error.
> For example, an expression in a select clause may cause an error if
> evaluated appropriately before filtering out rows by where clause.

I am not quite sure what you mean. I see no problem with a column alias that is unique within the expression. It might affect parsing speed, but not execution order.

Thanks for your feedback,
-T- Received on Wed May 15 2002 - 21:58:51 CEST

Original text of this message