>NO!!!! Setting Enginebehavior to 80 is the same as accepting that you may end up with the wrong data. Not a good solution!

So, in this case, you get a wrong one out of a pair of twins? Not good at all!

IOW, the term "wrong data" is wrong by itself, in the absence of definition of "right data". With enginebehavior 80 or 70, the definition is "values coming from any random record within the group-by", and all the values you may get are valid by that definition. Once you accept that randomness, like we did between FP2.0 - VFP7, you're fine. Or you can decide that you don't care, because the values are irrelevant or also candidates for group-by but not really because they are derived values (because we are perhaps denormalizing for a report, and one of those fields is customer name - where the customer's PK is already in the group-by - so since the name is the same for each record in the group, which of these same values are wrong and which is right?).

This argument that one among the random values may be right while all others are wrong - well, it sounds to me like a theoretical justification for the two random Joe Q Coders who didn't really understand what they were doing, so they got what they were not expecting, and then complained... In the end, the CYA logic led to "it's not deterministic, they guys aren't bozos, we can't have pseudo-random stuff coming out of our queries" (as if the order of records isn't already pseudo-random, and can't be guaranteed unless you specify it). So they straddled everyone with kilometer long group-by clauses just to avoid complaints (and, who knows, perhaps lawsuits), from future generations of Joe Qs.

So perhaps the group-by rules are forcing you to repeat ridiculous amounts of code (and if it's a long case statement you get to repeat that too), but at least it will save you from the perils of getting a random value.

I still liked the old one more.