Hi Jeff,

What about the scope clause in REPORT FORM? Anyway, I was working on fixing an app a while back where the author used SET FILTER in Form.Refresh. Ack!

As to using publics for SET settings, I use an environment object based on Custom and create properties to store/restore the settings.


>I disagree with the set filter part. Agreed, it shouldn't be used in place of a p-view or sql select but there are times when you need to set a filter - for instance a have a report cursor with a parent-child relationship. The parent cursor has multiple records but I only want the report to run for one parent record at a time (due to business rule/system requirements/faxing compatibility etc.) so my only choice is to set the filter to the unique key of that record, run the report, then turn the filter off.
>
>Setting a filter on an optimizable expression shouldn't hinder performance with smaller recordsets.
>
>I also see a place for public variables in saving and restoring SET settings when an app starts/ends.
>
>Let's be careful not to generalize. I wouldn't say "FORGET SET FILTER" or "NEVER USE PUBLIC VARIABLES". Instead, "LIMIT USAGE OF SET FILTER AND PUBLIC VARIABLES". Without seeing the specific situtation and business contraints that a particular app funcationality faces, you can't say that using Set Filter and public variables is inherently bad.
>
>Just my opinion.
>
>-JT