>>I don't know what is the reason, but you coud try it from command window using your own field/table names:
>>USE H:\vfp_cue\cue\dbf\TITLE.DBF && this is 950K rec table
>>_screen.addobject("grid1","grid")
>>_screen.grid1.visible=.t.
>>_screen.grid1.columncount=3
>>_screen.grid1.recordsourcetype=1
>>_screen.grid1.recordsource="TITLE"
>>select title
>>set filter to ttl_name="A"
>>_screen.grid1.refresh
>>set filter to ttl_name="B"
>>_screen.grid1.refresh
>>It works without any delays on my machine.
>
>I tested this code and it is as slow.
>
>What I tested is this:
>
>USE N:\INFOPLUS\DATA\INFOLIST\ACRONYM
>_screen.addobject("grid1","grid")
>_screen.grid1.visible=.t.
>_screen.grid1.columncount=3
>_screen.grid1.recordsourcetype=1
>_screen.grid1.recordsource="acronym"
>select acronym
>set filter to upper(acronym)="ABEND"
>_screen.grid1.refresh
>
>I have 350,000 records. SET OPTIMIZE is on as well as SET DELETE. The result gives 80 records.

Ok, now I at least reproduced the behaviour. When I have one-char filter condition, i.e. Name="A" it's going momentarily, 2-3 char already give visible delay, and 7 char killed VFP completely. Of course, when I try Select-Sql, it doesn't matter how long is condition string. So, it looks like a VFP-grid-filter rule: if filter condition length is more than 2-3, then filter is not applicable, and use cursor/view.