I'd guess that something in the list: Id, EntryDate, TranDate, EntityId is not unique and so you are getting one record for each unique combination. I'd guess that if you look at the records in order that you see more than one record for some batchid's.

SO, where before you got one record for each batchid, you are now getting one record for each entityid on each trandate on each entrydate for each id within a batch. If these values vary at all within a batch id, they cause a new record in your result set.

Actually your original query resulted in some fiction since the trandate selected (for example) could be different within the batch, but wouldn't be reflected in the resulting data set. It might be better to select only the batchid, and the count in the query. Doing so would result in the same number of records as your original query. Once you have that table, if you need the other data, do a join to obtain those values.

Personally I prefer the old behavior. Oh well.

>
>The second was redone in VFP8, to include the additional fields
>on the GROUP BY clause, yet now I seem to get a whole lot more
>records, but each CNT value is 1.
>
>Whats wrong here?
>
>
>SELECT Id, EntryDate, TranDate, BatchId, EntityId, Count(*) AS Cnt;
> FROM Resh;
> WHERE Resh.Status == " ";
> GROUP BY Resh.BatchId;
> ORDER BY Resh.BatchId;
> INTO CURSOR Temp1
>
>
>SELECT BatchId, Id, EntryDate, TranDate, EntityId, Count(*) AS Cnt ;
> FROM Resh ;
> WHERE Resh.Status == " " ;
> GROUP BY BatchId, Id, EntryDate, TranDate, EntityId ;
> ORDER BY Resh.BatchId ;
> INTO CURSOR Temp2