Roy,

<< I'll happily accept that but its rather counter intuitive to be able to
enter ORDER BY and have it ignored in some circiumstances. >>

That's the point: it's *not* ignored.  Think of ORDER BY as a *presentation*
mechanism.  Unless it is being applied to the end result set that you're
seeing as a result of the outer query, then it is meaningless in terms of
how rows are visited for selection/aggregation purposes.  The *only* reason
that it is even allowed in derived tables is so that the RANGE clause can be
used to limit an ordered set of rows.

Tim Young
Elevate Software
www.elevatesoft.comi

Roy,

<< Only a trivial one - which direction does it sort? >>

 Ascending, as you well know.  Is this a request for an asc/desc clause
?

Tim Young
Elevate Software
www.elevatesoft.com

Tim


><< Only a trivial one - which direction does it sort? >>
>
>Ascending, as you well know. Is this a request for an asc/desc clause
>?

I *guessed* it would be ascending I just wanted to make sure. I'm not asking for an asc/desc clause. Where I'm using LIST and am bothered about the order ascending is what I'm looking for. Now if only you could come up with a way of treating the result of a LIST as a stringlist without having to put it into one.........

Roy

ps Whilst walking the dogs this morning I just wondered about this

>I used "ordered" instead of "order by" to keep things less confusing with
>really complicated SQL statements.

Is that for you, us or the parser

>>select list(ordered Company) FROM customer

>>select list(distinct ordered Company) FROM customer

WOW: Thanks Tim! This is a minor but powerfully useful addition, as it allows direct comparison of such lists using the "=" operator so long as you know they are identically sorted. This allows you to test a question like "has sensor "A" received all the same data points as sensor "B"?" much more easily.

><< Only a trivial one - which direction does it sort? >>
>
>Ascending, as you well know. Is this a request for an asc/desc clause
>?

ASC / DESC option isn't necessary for my purposes ... but while you're at it you might as well??

Roy,

<< I *guessed* it would be ascending I just wanted to make sure. I'm not
asking for an asc/desc clause. >>

Oops, sorry - thought you were being "cheeky" in your typical way.

<< Where I'm using LIST and am bothered about the order ascending is what
I'm looking for. Now if only you could come up with a way of treating the
result of a LIST as a stringlist without having to put it into one.........
>>

That, unfortunately, would require some changes to the TField components.
However, you do know that you can directly assign one (TBlobField) to the
other (TStrings), right ?

<< Is that for you, us or the parser >>

It doesn't matter to me or the parser, it's basically the same either way:

"Ordered"

        if SkipSymbol(EDB_EXPRSTR_DISTINCT) then
           begin
           TokenID:=DISTINCT_AGGREGATE;
           if SkipSymbol(EDB_EXPRSTR_ORDERED) then
              TokenID:=DISTINCTORDERED_AGGREGATE;
           end
        else if SkipSymbol(EDB_EXPRSTR_ORDERED) then
           TokenID:=ORDERED_AGGREGATE;

"Order By"

        if SkipSymbol(EDB_EXPRSTR_DISTINCT) then
           begin
           TokenID:=DISTINCT_AGGREGATE;
           if SkipSymbol(EDB_EXPRSTR_ORDER) then
              begin
              ErrorIfNotSkipSymbol(EDB_EXPRSTR_BY);
              TokenID:=DISTINCTORDERED_AGGREGATE;
              end;
           end
        else if SkipSymbol(EDB_EXPRSTR_ORDER) then
           begin
           ErrorIfNotSkipSymbol(EDB_EXPRSTR_BY);
           TokenID:=ORDERED_AGGREGATE;
           end;

Of course, the parsing is never really the issue, it's all of the stuff that
happens afterward that is normally the tricky part.

Tim Young
Elevate Software
www.elevatesoft.com

Tim


><< I *guessed* it would be ascending I just wanted to make sure. I'm not
>asking for an asc/desc clause. >>
>
>Oops, sorry - thought you were being "cheeky" in your typical way.

I do try and put on when I'm joking

><< Where I'm using LIST and am bothered about the order ascending is what
>I'm looking for. Now if only you could come up with a way of treating the
>result of a LIST as a stringlist without having to put it into one.........
> >>
>
>That, unfortunately, would require some changes to the TField components.
>However, you do know that you can directly assign one (TBlobField) to the
>other (TStrings), right ?

Yup. Its just that something like table.fieldbyname('bumph').asstringlist[37] would be neat.

><< Is that for you, us or the parser >>
>
>It doesn't matter to me or the parser, it's basically the same either way:
>
>"Ordered"
>
> if SkipSymbol(EDB_EXPRSTR_DISTINCT) then
> begin
> TokenID:=DISTINCT_AGGREGATE;
> if SkipSymbol(EDB_EXPRSTR_ORDERED) then
> TokenID:=DISTINCTORDERED_AGGREGATE;
> end
> else if SkipSymbol(EDB_EXPRSTR_ORDERED) then
> TokenID:=ORDERED_AGGREGATE;
>
>"Order By"
>
> if SkipSymbol(EDB_EXPRSTR_DISTINCT) then
> begin
> TokenID:=DISTINCT_AGGREGATE;
> if SkipSymbol(EDB_EXPRSTR_ORDER) then
> begin
> ErrorIfNotSkipSymbol(EDB_EXPRSTR_BY);
> TokenID:=DISTINCTORDERED_AGGREGATE;
> end;
> end
> else if SkipSymbol(EDB_EXPRSTR_ORDER) then
> begin
> ErrorIfNotSkipSymbol(EDB_EXPRSTR_BY);
> TokenID:=ORDERED_AGGREGATE;
> end;
>
>Of course, the parsing is never really the issue, it's all of the stuff that
>happens afterward that is normally the tricky part.


Now what you should have done there is use EDB_EXPRSTR_ORDERED for both and that would really have confused me <vbg>

Roy