[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