665abaa3   
   From: hugo@perFact.REMOVETHIS.info.INVALID   
      
   On Fri, 17 Sep 2010 11:47:06 -0700 (PDT), Dom 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.   
      
   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:   
      
   >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.   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)