Andrus,

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?