This looks familiar. As I came to realize back in June, FOCUS's "WITHIN" and SQL's OVER() are generally not equivalent. But for count distinct, if the underlying column is the sort key, they are: the number of distinct values within each sort-key value is guaranteed to be 1, and the sum of those 1's over the rows of the answer-set (which is what WITHIN TABLE means in Focus) equals the count of distinct sork-key values at large (which is what "count(distinct ...) over ()" means in SQL).

So if one changes CNT.DST.ACTIVITYTYPECODE WITHIN TABLE AS CNT_PARTYID in this request to CNT.DST.PARTYID WITHIN TABLE AS CNT_PARTYID, Focus could validly generate SQL with windowing:

select
PARTYID,
count(distinct PARTYID) over (),
...
sort by PARTYID
group by PARTYID
...

which is valid in most SQL dialects -- and equivalent to the Focus code without any dependence on the WHERE clauses -- without tripping over the focus two-verb-to-single-select translation issue.

But I don't know whether the Focus engine is sharp enough to do so.

- - -

However, Francis M. already noted (op. cit.) that CNT.DST.PARTYID is off-limits here because of SQLMSS restrictions on Uniqueidentifier columns.

So it's

TABLE FILE MSEXT_ACTIVITYPOINTER
SUM
-*CNT.DST.ACTIVITYTYPECODE WITHIN TABLE AS CNT_PARTYID
  MIN.PARTYIDNAME
  MIN.ACTIVITYTYPECODE
BY PARTYID
WHERE SCHEDULEDSTART FROM DT(20071101 00:00:00.000) TO DT(20080131 23:59:59.999);
WHERE CF_COMPANYIDNAME EQ 'BMO Nesbitt Burns Inc.';
WHERE ACTIVITYTYPECODE EQ 4201;
WHERE PARTYOBJECTTYPECODE EQ 2;
WHERE PARTICIPATIONTYPEMASK EQ 5;
ON TABLE HOLD
END

TABLE FILE HOLD
SUM CNT.DST.PARTYID WITHIN TABLE AS CNT_PARTYID
  MIN.PARTYIDNAME
  MIN.ACTIVITYTYPECODE
BY PARTYID
ON TABLE HOLD AS #H001M1 FORMAT SQLMSS
END

Francis and I work together and in June we were created a similiar report but this one is more complicated, that's why the data looks fimiliar.

Yea CNT.DST.PARTYID doesn't work. I've tried that.