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

Yes, that's one solution :) As far as NOFILTER, I recommend it for situations where you're displaying a cursor, that's one of two situations where I've encountered problems, with grids suddenly displaying non-sensical results to users.

The other is maybe worse, when you USE DBF() AGAIN to make a write cursor, this will cause a crash if a filtered table is the SQL result...

I use NOFILTER now almost always in code for one-table SQL to cursors, but usually not in Command window table queries, where I want quick results and don't need to do anything else with cursor...