The Grid class would pay attention in Dynamical re-asigment of RecordSource:

I would create the RecordSource as an updateable cursor defined in the form's Load method using the CREATE CURSOR command. Add a custom ResetGrid() method to the grid class to populate the cursor by ZAPping it, SELECTing the appropriate records into a temporary cursor and then appending the records from the temporary cursor into the one defined as the grid's RecordSource.

SELECT ( This.RecordSource )
ZAP
SELECT * FROM < Some Table > ;
   WHERE < Some Condition > ;
     INTO CURSOR Temp NOFILTER
SELECT ( This.RecordSource )
APPEND FROM DBF( 'Temp' )
USE IN Temp
GO TOP IN ( This.RecordSource )
This.Refresh()

There are a few reasons for doing it like this. First, you can set the categories grid up visually in the form designer since its RecordSource exists prior to instantiation. More important is the fact that a grid does not like having its RecordSource ripped out from under it. If the grid's RecordSource were updated by SELECTing into it directly, it would appear as a blank grey blob on the screen. This is because the SELECT closes the cursor and effectively leaves the grid hanging in mid air, so to speak. ZAPping it, on the other hand, does not.

One way to avoid having the grid turn into a blank grey blob is to set its RecordSource to an empty string before running the SELECT and then resetting it afterward. Although this will work in the simplest of cases, it is not a solution we recommend. While it will keep your grid from losing its mind, the grid's columns still lose their ControlSources and any embedded controls. So, this works if your grid uses base class headers, base class text boxes, and displays the fields from the cursor in exactly the same order as they are SELECTed. Otherwise, you have to write a lot more code to restore all the things that get lost when the grid is re-initialized.