>>>>>I am using a grid based on local view.
>>>>>Local view is based on table having many records and returns all the records.
>>>>>Prb: Local view creation scans ALL the records from base table and
>>>>>this works VERY slowly! So it is not possible to use local views
>>>>>for large data manipulation!? Fetchsize works for remote views only.
>>>>>
>>>>>If I use table-based grid instead of view, it appears immediately,
>>>>>if there are many records returned from table. But when filter condition returns only a few rows, table-based grid causes FoxPro to
>>>>>hang, but browse command works. Since there are many different queries, I cannot pre-build a index for table.
>>>>>So it is not possible to use table-based grid also!
>>>>>
>>>>>So, it is not possible to use grid control at all for large data manipulation!
>>>>
>>>>If you return many many records from multiple tables and it's slow, then you could look at way you represent the data in grid. The token here is that it's not necessary to join all tables. It will be faster (or much faster) to diversify Column.ControlSource properties making lookups into related tables. The reason here is that controlsources evaluated for visible part of grid only, i.e. 15-20 times, and joins in Select-SQL will be run for thousands/millions of records.
>>>
>>>Edward, I have a trivial create view command based on a large single dbf file.
>>>My problem is that create local view scans all rows from base table.
>>>Is it possible to use it in this way, that only required part of
>>>base table will be scanned? FetchSize works for remote views only.
>>>Is the create local view really so stupid?
>>
>>What kind of buffering do you use for this view?
>
>I don't use any buffering. My tables are free tables.
>I create an empty database (required for views) and issue
>create local view command to select most data from free dbf file.
>
>I think that bufering affects only to update, not for row selection.

Actually, i asked you what buffering do you use for the view. The idea is that table buffering is not applicable well for high-volume recordset and row buffering is not appropriate well for grid representation, so you can just trash your view and bring the table which is instantenous.