Posted by bwalton_707 on 11/27/07 22:33

On Nov 27, 3:32 pm, --CELKO-- <jcelko...@earthlink.net> wrote:
> You use reserved words for data elements. You have multiple names
> for the same data element. You used vague data element names,
> including the magical, universal "id" that applies to all things in
> creation.
>
> You don't know that the ORDER BY clause is part of a cursor in
> Standard SQL and that it comes at the end of the SELECT statement.
> You seem to have both an invoice number (the usual term) and an
> invoice identifier (I am scared that you used IDENTITY as a fake
> pointer and have assumed that the data is stored in phsycial order,
> like a mag tape).
>
> I think that you are trying to use ordering because you do not know
> what a table is -- no ordering! You want a sequential file. That is
> not how RDBMS works at all! Totally wrogn mindset.
>
> This is the usual template for finding the latest invoice is:
>
> SELECT I1.invoice_nbr, C.customer_name, C.shopping_addr, C.acct_nbr
> FROM Invoices AS I1,
> Customers AS C
> WHERE I1.acct_nbr = C.acct_nbr
> AND I1.posting_date
> = (SELECT MAX(I2.posting_date)
> FROM Invoices AS I2
> WHERE I2.acct_nbr = C.acct_nbr);
>
> Notice how I cleaned up the names. You might want to read ISO-11179
> sometime soon.
>
> >> Neither SELECT statements are supported in SQL Server 2005... Is there a logical reason WHY? Other then ANSI Standards which I'm not buying as m$ft rarely follows any standards but there own 100% of the time anyway. <<
>
> Both logic and Standards. And Microsoft has been moving very strongly
> to ANSI Standards; look at the new stuff in SQL-2005 and SQL-2008
> which is pure ANSI. The TOP syntax is proprietary syntax; the ANSI
> approach would use ROW_NUMBER() OVER() instead.
>
> What sense would it make to sort a table (a contradiction by
> definition) then group it? You have no idea what a SELECT does and
> want it to act like a READ() in a proceudral languages.
>
> 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) 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.
>
> b) 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.
>
> c) 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).
>
> d) 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.
>
> e) 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).
>
> f) 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.
>
> g) 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.


Thanks for the reply, unforunately your solution is not completely
accurate because it will return multiple records
if they have the same datetime (posted) date which is not the desired
result.

I did not develop that nonsense syntax it is supported in visual
foxpro and returns the correct results in a single select statement.
VFP was developed by dave fulton the acquired by microsoft so I
assumed they developed it ... Moveover it works!


Bryan

[Back to original message]