>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.


No, you don't. You can use SQL to gather your data. you can use the FOR or while clause of the report form command to limit the data, you can use the SET KEY command to limit your data, ... I've built alot of systems and I can count on one hand the number of times I have ever used SET FILTER.

>Setting a filter on an optimizable expression shouldn't hinder performance with smaller recordsets.

SET FILTER whether optimized or not , is slower than no SET FILTER. Speed is a relative consideration not an absolute.

>I also see a place for public variables in saving and restoring SET settings when an app starts/ends.

That is a good example of a misuse of variables. Variables are variable not persistent. Saving vars to a mem file has its own set of problems. But even still, if you save and restore the vars in the startup program they don't need to be public, they can be private.

>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.

When instructing new developers it is good to generalize. It makes them think before they act. If an instructor says, PUBLIC vars are sometimes OK, that is a blanker permission to use publics. If he says NEVER use public vars, that makes a learner think really hard before they use a public.