Hi Rodney,
>>>
>>>Yes, I'm using queries. I don't really have an option to use views for this particular project (at least I don't think I do). It is working, but there is still a huge lag time when I reset the RecordSource after the query was done. Do I not need to reset the RecordSource after requerying the data?
>>
>>If your grid uses RecordSourceType 1 (Alias) and this Alias is a Cursor created with an SQL Query, you MAY need to do as I suggested. i.e.

>>grid.RecordSource = ""
>>SELECT cols FROM table WHERE somecondition INTO CURSOR somecursor NOFILTER
>>grid.RecordSource = "somecursor"

>>
>>If you just execute the SQL, VFP will re-create the grid. Any custom controls, methods, and properties will be lost. If you started with a grid with ColumnCount = -1, this will not be a problem.
>>
>>Does that help?
>
>Bill,
>
>On further review, here's basically what I'm doing and where I'm seeing major lags.
>
>1. I have a cursor defined by an SQL query prior to loading the form.
>2. Form is loaded.
>3. Filter condition is entered. This triggers the following:
>a. THISFORM.grid.RecordSource = ""
>b.
>c. THISFORM.grid.RecordSource = "cursor"
>
> *-- Code to reset the columns.
>d. FOR ln_counter = 1 TO THISFORM.grid.ColumnCount
>e. WITH THISFORM.grid.Columns[ln_counter]
>f. IF NOT EMPTY(.Name)
>g. .ControlSource = THISFORM.grid.RecordSource + "->" + ;
>h. SUBSTR(.Name, 4) && named such that this works properly
>i. ENDIF
>j. ENDWITH
>k. ENDFOR
>
>I see time lags at (c), and (g) of approximately 4 minutes each. Hopefully this clarifies things. I know I'm doing something wrong because I'm sure I've seen applications that handle this size of data and have this flexibility in them.
>

The primary question I have is this: Are you using the NOFILTER clause in your SELECT statement? If not, VFP is probably creating a filtered cursor for you. Notoriously slow with grids. <G> Other than that what you have looks good.

Bill Armbrecht
VFP MCP