No guru here, Steve, but SET ENGINEBEHAVIOR 70 will get you out of the catch-22.

good luck

>I understand the VFP compliance with SQL standards, and in general agree with that compliance. However, that has created a catch 22 problem, which if I have been informed correctly, the standard, seems to be a purist dream, but a real world nightmare.
>
>SQL standards require, that when an aggregate field is included in a SQL Statement, a Group by clause is mandatory, and all non-aggregate fields must be included in the Group By clause. Memo fields can't be included in a Group By clause, but the Engine requires ALL fields, including any Memo fields to be included. Ergo, a VFP8 compliant view cannot be created to drive a form. IOW:
>
>Rule #1: A memo field can't be included in a Group By clause.
>Rule #2: All non-aggregate fields must be included in the Group By clause. When VFP8 objects, refer to Rule #1.
>
>It has been suggested to me that aggregate fields should never be included in an editable view. I consider that to be just plain silly, but even if that point were to be conceded (I won't), a SQL cursor couldn't even be created to drive a report. Yeah, I know the report writer can do some aggregation, but the data is often cleaner (and may well be faster) when created with a SQL statement. But the report engine isn't the issue here. ANSI SQL syntax is.
>
>Would some of the VFP gurus care to comment on this issue, and perhaps suggest solutions (other than trimming a memo field into a character field which is not an option) ???