>>Without NOFILTER you trust VFP to decide (and it may decide differently every time) how the cursor will be created: as physical file or as filter on real table. With NOFILTER you make sure that it's physical file.
>
>And vfp's decisions are such that an SQL will work fine without NOFILTER hundreds of times on different machines over months, and then all of sudden, Big Problem With Filtered Table in app...so NOFILTER is now essential, really, for most situations...


Bruce, what was different about this situation that I complained about was that I create the cursor, then add a new master record (which involves lots of codebook processing). I expected the cursor to be valid when I returned from new() but it wasn't. So adding NOFILTER fixes that.

Now I have upwards of a hundred other SQL select statements where I use the result immediately, typically to display a browse picklist for the user, and never need it again. I've never seen these fail. Would you advise adding NOFILTER to these selects?

In regard to deleted records. In most cases I never allow my users to delete records. I consider them to be part of the audit trail. In those case where I do allow it, I change the primary key values in such a way as to remove them from consideration in the future. So my solution is: SET DELETED OFF.

Peter