Yeah, DBlank, you might be right. Hadn't thought of the subreport aspect, as I generally don't use them, but depending on how the subreport/report is structured Takesen's solution may not work either as the fields may not be available. I think that the report can be suppressed, but the problem is going to be that the report....
Guys, I think that we have been barking up the wrong tree, could be wrong, but the subreport is returning a date...just a date and he wants to sort on it...that's not really grouping, but at the same time, you can't sort the main report's data based on a subreport value, and placing the subreport in the header isn't do it either.
The most efficient way to accomplish this is to have the sort criteria in the main report's data...either stored proc/view or join the data (which might cause duplicates). Of course I vote for stored procs, because they give you the flexibility to do this sort of this, as well as bring in the data for the subreport all in one row. then it is just a matter of displaying, but at the very least a sort date field could be added to the row.
Now the reason that I changed my mind is of how I think of Crystal working....it reads a row of data for the main report/formats it, then if it needs to it reads the subreport data/formats it, and reads the next row...DBlank is right, it doesn't know the sort value until tool late.