Not sure where the "Had to be bad coding" comes in.
For example, if you did "select * from employee where last name = 'Smith'" you would get a cursor of only those employees. The employee table would still be open, but VFP opened it again, in a different work area, with a different alias, and then put a set filter. Edits to this cursor would be written to the actual source table.
Originally, we would add a calculated field which then forced VFP to create a truly new cursor. So we might do something like "select employee.*, date() as somedate from employee where last name = 'Smith'". Finally, MS added the nofilter clause that we could use instead. This insured that when we used Select, we always had a new cursor and could edit it as we desired without affecting the source table.
Fletcher
Fletcher Johnson FletcherSJohnson@Yahoo.com LinkedIn.com/in/FletcherJohnson twitter.com/fletcherJ strava.com/athletes/fletcherjohnson 408-946-0960 - work 408-781-2345 - cell
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Man-wai Chang Sent: Sunday, May 19, 2019 9:42 PM To: ProFox Email List Subject: Re: Filtering Oddity
On Sat, May 18, 2019 at 12:01 AM Fletcher Johnson FletcherSJohnson@yahoo.com wrote:
- It used to be that a Select statement would be optimized by VFP to open
the source table again, in another work area, and then set a filter on it. This was a problem when people thought they had a cursor and updated the contents, only to find out they had edited the actual data. So they added
a
"nofilter" clause that forced VFP to create a new cursor and not use the original approach.
Had to be bad coding, possibly mixing up aliases in the process.
- I can't remember, but did set filter allow you to reference a variable?
And, if so, did changing that variable then change the effect of the
filter?
If so, this might also be an option.
SET FILTER can use variables. Changing the values of the variables should not affect executed SET FILTER if I remember correctly.