Myron:

If i want to examine a table, I usually do an

use invoice_headers
browse

I never actually look for all records, but I can use
Table / Go bottom, go top,
Edit/Find etc.

commands to examine naturally ALL the invoices.
This command works very fast and is very convenient.
For record filtering, I can add
FOR clause to browse command and this works faster than
equivalent grid+ set filter command.

I want the same functionality to be available to users.
Since grid with set filter causes VFP to stop respondig when
there are only few records from large data to be returned, I
desided to use local view for unified table access in all query
conditions.
I'm VERY surprised that this will work.
Query builder allows users to build arbitary logical expression
for searching invoice headers and I must find some methods to
allow edits results as quickly as browse command does.

The grid is only control which allows to display and edit
as many data as fits to screen in compact form and my program
uses it in most places.
If it is not possible to put grid to display
data rapidly, Visual FoxPro cannot be used for data
processing at all!!

>IMO scroll through an entire large table is not something
>that I would want to put in an application for day-to-day
>use. Normally, someone doesn't just scroll through
>1000+ without some reason. Check to see what they
>are actually looking for and maybe you can give
>them a better tool to use.
>
>Alternately, you could have a summary view of the invoice
>headers. Additionally, have a parameterized detail view.
>Have a cmd button the works with your detail view to go
>to the next invoice which you could determine by your
>summary view.
>
>-myron kirby-
>====================================================
>
>>Myron,
>>
>>sometimes user wants simply to see and edit a list of all
>>invoices, customers etc. in single table.
>>He can scoll up and down, page by page.
>>It must be solved by using single grid from single local view.
>>I'm wondering that this cannot be done using local views.
>>Are local views really so limited?
>>
>>
>>>That does make difficult without some of the features of the
>>>remote views. Using the selection criteria method what
>>>number of records are you indicating is a large return
>>>set that would cause it to be slow. I would think that if you
>>>are talking about 1,000+ that there would be come type
>>>of logical sub-categories in this grouping. If there is
>>>you could have a pageframe that you should these
>>>have a summary view that should these sub-grouping.
>>>Then the user selects a sub-group and the goes to the
>>>sub-group detail page which is a grid whose data source is a
>>>parameterized view based on the sub-group the user
>>>selected.
>>>
>>>-myron kirby-
>>>=======================================
>>>>What to do when selection criteria returns a lot of rows?
>>>>
>>>>This causes local view requery to scan the whole table.
>>>>Actually, it is sufficient to display only few of them in view-based
>>>>grid. More rows are required only when user selects next page
>>>>in the grid.
>>>>
>>>>>When I have large tables, I will normally use a parameterized view and set my View.NoDataOnLoad to .T.
>>>>>Then I will provide the necessary selection criteria options where my users can focus on
>>>>>the records they want to work with and the application minimizes the network traffic.
>>>>>
>>>>>-myron kirby-
>>>>>=================================================
>>>>>>>>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?