>>>>>And remember that "the first expression it processes" might be completely random to you. So it might run fine in testing environment and on site it's a complete desaster.
>>>>>
>>>>>(^_^)
>>>>
>>>>One of the first things you learn in Fox's SQL is that there is no guarantee that records retrieved will come in any particular order. With a single table filtering cursor it may be, most of the time, the recno() order... but you can't rely on that. Anything more complicated than that, you just don't know.
>>>>
>>>>Relying on records being read in any order is just as a stable house of cards as is relying on instantiation order of objects. May change with the wind.
>>>
>>>Not quite true... the particular order is ALWAYS the order specified by the execution plan. If you don't specify an ORDER, it'll set one for you :) But, we can take consolation that all the SQL engines I know work the same way < g >
>>
>>Not quite shure if I read you right. But by definition SQL works and returns in sets rather then in lists / tables. So if you assume nothing on any particular order accept output order set by the ORDER BY clause you will not be wrong. (^_^)
>
>It's a subtle distinction. Yes, it's wise to assume no particular order in the result set if no ORDER BY is specified. But, that is not the same as the result set's order being random.
>
>If you could somehow guarantee that all the factors of importance to the SQL engine and its execution plan were the same between repeats of the same query (cache/buffer states, CPU/memory availability, ...), then the resultant order will be the same each time. It may appear random to mere mortals, but it isn't.

You right on that. I only point out that the definition of SQL is just a set with no particular order or something to guess how it works internaly.