[thelist] SQL Statement problem
Seth Bienek
seth at sethbienek.com
Mon Feb 11 22:22:01 CST 2002
Hi Rudy,
> > Frickin' SQL Server query builder keeps taking liberties with
> > my queries..
>
> well, seth, it's kinda hard to imagine that it knew the level of AND and
> OR evaluations that you *meant* to have, but substituted parentheses
> *that changed the semantic intent* -- i just don't believe it does that
I SWEAR it does. Well, not sure about the semantic intent, BUT I know for SURE
it moves my "nested" parenthesis around. Wether the results are different, I
havent checked (I imagine they would have to be), but it is an undisputable fact
that this happens. I seen it time after time. I always fix the parens when I'm
done.
> i'm sorry to make such a big deal about this but perhaps you missed the
> implication in my last post
I think I understood the implication in your last post. I am also aware of how
placement of parenthesis determines computational order (one of the few things
that stayed with me from high school algebra). ;)
> referring to your original query, would a row with terminate_date
> 02/02/2002 and terminate_type 'declined' and company_key 'FU'
> satisfy the WHERE clause?
Yes. ;)
> view *definitions* are stored in the database catalog, but they don't
> actually have any data
Ok. This makes sense.
> when you write a query against a view, the query definition and view
> definition are "merged" and the resultant database request is executed
This is a very cool thing.
> ...
> it's the same thing as the difference between a subquery and a join --
> the database engine is going to resolve how to execute it, and you needn't
> worry about it
Something I am grateful for.
<lots of useful code and instruction snipped>
You are a God. :) I have written the convoluted part of the query into a view
and have since made it much more convoluted (and useful).
Thanks again for the great guidance!
Regards,
Seth
More information about the thelist
mailing list