>>However, I have a few with "SELECT *" and 50-75 fields involved, and only 1 or 2 critical GROUP BYs in the SQL.
>>
>>Anyone have a good recommendation for me to handle these?
>
>
>Split the SQL in parts.
>
>Get all the ids and "group by" fields grouped in the first SQL and run a second sql to get the rest.
Back again: Okay, I've been working on this a while now, and I can see your concept is the right solution.
The only serious problem I've encountered with splitting complex SQLs is the need to "test them to death" to ensure the result sets, following breakups, are always the correct, same results as the old way of GROUP BY, for all data situations.
I certainly can't conceive of anything better than your idea, and logic tells me there is no other solution. But I'll just break the splits in very gradually, leaving Enginebehavior on 7, while I make all the changes. There's no need to rush this change, anyway.
And, thanks again.
The Anonymous Bureaucrat,
and frankly, quite content not to be
a member of either major US political party.