I was always told that the order of execution in T-SQL was FROM,
SELECT, WHERE. This turns out to be important if you want to avoid
certain errors, such as "divide by zero" error.

But now look at the following table:

ID Name Pos
1 Dom 1
1 Kim 2
1 Sam 3


In the following, it looks like the windowing function is done AFTER,
not BEFORE, the where clause:


select Name, max (Pos) over (partition by Group_ID)
from T_Table
where Last_Name < 'S'

The value for max (Pos) is 2, not 3.

Why did that happen?

On Fri, 17 Sep 2010 09:10:53 -0700 (PDT), Dom wrote:

Hi Dom,

The WHERE clause uses the Last_Name column, not the Name column that is
used in the SELECT list.
If that is a typo in your post, then I can't reproduce the issue. Here
is what I tested:

CREATE TABLE test
(ID int NOT NULL,
name varchar(10) NOT NULL,
pos int NOT NULL,
PRIMARY KEY (ID, pos));
go
INSERT INTO test
SELECT 1, 'Dom', 1 UNION ALL
SELECT 1, 'Kim', 2 UNION ALL
SELECT 1, 'Sam', 3;
go
SELECT name, MAX(pos) OVER(PARTITION BY ID)
FROM test
WHERE name < 'S'
go
DROP TABLE test
go

And the results:
name
---------- -----------
Dom 2
Kim 2

If you want me to investigate further, then please post some code to
reproduce the problem. See www.aspfaq.com/5006 for some suggestions how
to assemble the required information.

--
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis

On 2010-09-17 18:10, Dom wrote:
I don't see anything controversial about that. What do you expect from a
query like:

select Id, max (Pos)
from T_Table
where Last_Name < 'S'
group by Id

1,3 or 1,2?

If you want to investigate how it is defined (not exactly a walk in the
park though :-), you can download draft documents of the standard from:

http://www.wiscorp.com/SQLStandards.html

For the 2003 variant the relevant document is named
5WD-02-Foundation-2003-09.pdf


/Lennart

On Sep 17, 2:39*pm, Lennart Jonsson <erik.lennart.jons... (AT) gmail (DOT) com>
wrote:
Hugo. Yes, that was a type. Sorry. But you reproduced the results
that I got. The problem is that I thought max (pos) would give me 3
instead of 2, since I thought the WHERE clause did not kick in until
after the SELECT clause did it's work.

On Fri, 17 Sep 2010 11:47:06 -0700 (PDT), Dom wrote:

Hi Dom,

I'm sorry. I had not read your first post well enough.

On Fri, 17 Sep 2010 09:10:53 -0700 (PDT), Dom wrote:

Wrong. The LOGICAL order of processing is FROM, WHERE, GROUP BY, HAVING,
SELECT, ORDER BY. That is, the SELECT comes after WHERE (and HAVING).

It's also important to remember that this is the LOGICAL order of
processing. Databases are free to change that order, as long as the
results are the same. Not everyone agrees on whether getting divide by
zero errors because of this order changing is acceptable, but fact is
that SQL Server can do that. A query such as

SELECT Column1 / Column2
FROM SomeTable
WHERE Column2 <> 0;

can produce divide by zero errors, even though it should not when the
logical processing order is strictly followed. (In this simple case, you
probably won't get the error, but with some extra complexity thrown in,
it is perfectly possible).
If you want to preven divide by zero, rewrite this as

SELECT Column1 / NULLIF(Column2,0)
FROM SomeTable
WHERE Column2 <> 0;

--
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis

Here is how a SELECT works in SQL ... at least in theory. Real
products will optimize things, but the code has to produce the same
results.

a) Effectively materialize the CTEs in the optional WITH clause.
CTE's come into existence in the order they are declared so only
backward references are alllowed. A CTE can be recursive. Think of
them as VIEWs that exist only in the scope of the query. In practice,
if they are used once then they are implemented as an in-line macro.

b) Start in the FROM clause and build a working table from all of the
joins, unions, intersections, and whatever other table constructors
are there. The <table expression> AS <correlation name> option allows
you give a name to this working table which you then have to use for
the rest of the containing query. Ther are UNIONB, INTERSECT and
EXCEPT set construtors, LATERAL tables, table-valued funcitosn and all
kinds of things happening in here.

c) Go to the WHERE clause and remove rows that do not pass criteria;
that is, that do not test to TRUE (i.e. reject UNKNOWN and FALSE).
The WHERE clause is applied to the working set in the FROM clause.

d) Go to the optional GROUP BY clause, partiton the original table
into groups and reduce each grouping to a *single* row, replacing the
original working table with the new grouped table. The rows of a
grouped table must be only group characteristics: (1) a grouping
column (2) a statistic about the group (i.e. aggregate functions) (3)
a function or constant(4) an expression made up of only those three
items. The original table no longer exists and you cannot reference
anything in it (this was an error in early Sybase products).

e) Go to the optional HAVING clause and apply it against the grouped
working table; if there was no GROUP BY clause, treat the entire table
as one group.

f) Go to the SELECT clause and construct the expressions in the list.
This means that the scalar subqueries, function calls and expressions
in the SELECT are done after all the other clauses are done. The AS
operator can also give names to expressions in the SELECT list. These
new names come into existence all at once, but after the WHERE clause,
GROUP BY clause and HAVING clause have been executed; you cannot use
them in the SELECT list or the WHERE clause for that reason.

If there is a SELECT DISTINCT, then redundant duplicate rows are
removed. For purposes of defining a duplicate row, NULLs are treated
as matching (just like in the GROUP BY).

g) Nested query expressions follow the usual scoping rules you would
expect from a block structured language like C, Pascal, Algol, etc.
Namely, the innermost queries can reference columns and tables in the
queries in which they are contained.

h) The ORDER BY clause is part of a cursor, not a query. The result
set is passed to the cursor, which can only see the names in the
SELECT clause list, and the sorting is done there. The ORDER BY
clause cannot have expression in it, or references to other columns
because the result set has been converted into a sequential file
structure and that is what is being sorted.

As you can see, things happen "all at once" in SQL, not "from left to
right" as they would in a sequential file/procedural language model.
In those languages, these two statements produce different results:
READ (a, b, c) FROM File_X;
READ (c, a, b) FROM File_X;

while these two statements return the same data:

SELECT a, b, c FROM Table_X;
SELECT c, a, b FROM Table_X;

Think about what a confused mess this statement is in the SQL model.

SELECT f(c2) AS c1, f(c1) AS c2 FROM Foobar;

That is why such nonsense is illegal syntax.

own golden rule by not providing DDL:
CREATE TABLE foobar(c1 INTEGER);
or
CREATE TABLE foobar(c2 INTEGER);

Of course
CREATE TABLE foobar(c1 INTEGER, c2 INTEGER)
will work just fine.

--
Serge Rielau
SQL Architect DB2 for LUW
IBM Toronto Lab

On Sep 18, 5:55*pm, Serge Rielau <srie... (AT) ca (DOT) ibm.com> wrote:
Thanks to everybody. Cleared up a lot.

Dom