paul 69344 wrote:
This is a "Works As Designed" feature that makes me wonder just what the logic was for that design. 40 years of experience shows a pattern to this; there is a warning in the documentation which is a hint that it's just how it is, and by documenting it any weird behaviour becomes WAD instead of a bug. Usually this kind of thing comes up during Beta testing, and we push the manufacturer to document it because it's so damn weird that no-one would expect it to happen.
Which aspect of correlated subquery activity are you criticizing here Paul?
It always seemed perfectly sensible to me, apart from an omission - when a column is available from either the inner or the outer query, SQL Server should require aliasing and error with "Ambigous columnname" where appropriate. This alone would eliminate most of the disputes over correlated subquery peccadilloes.
[font="Arial"]“Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw[/font]
For fast, accurate and documented assistance in answering your questions, please read this article
Understanding and using APPLY, (I)[/url] and
(II)[/url] Paul White
Hidden RBAR: Triangular Joins[/url] /
The "Numbers" or "Tally" Table: What it is and how it replaces a loop[/url] Jeff Moden