Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Vfp bug: rushmore fails with set filter and grid
Message
From
06/05/1998 12:53:21
 
 
To
06/05/1998 12:30:39
Cetin Basoz
Engineerica Inc.
Izmir, Turkey
General information
Forum:
Visual FoxPro
Category:
Troubleshooting
Miscellaneous
Thread ID:
00096421
Message ID:
00097416
Views:
40
Cetin,

This select takes very long time if there are many records returned.
set filter works much faster since it will not scan whole table.
Also this does not change base table.
I want to edit data in large table where records are filtered
by an arbitrary (rusmore optimizable because there are some indexes) condition.
I want to edit filtered records in a grid.

>Then select into an editable cursor.
select ... where .t. into cursor tcTemp
>use dbf("tcTemp") in 0 alias tcEdit
>use in "tcTemp"
>select tcEdit
>* ...grid.recordsource = ""
>* ...grid.recordsource = "tcEdit"
Cetin
>
>>Users want to edit the queried records, selecting into cursor
>>does not allow this. How to allow them to edit queried data in a grid?
>>
>>I think the problem is that set filter is rushmore optimizable,
>>but set filter + grid is not rushmore optimizable (grid refresh will
>>not use ruhmore for some reason)
>>
>>>I guess I'd try converting their query input into a SELECT instead of a filter and create a cursor. Fox will have to scan the whole table for either a filter or a select unless there are indexes to support rushmore optimization. I've never had to be concerned about Fetchsize so I don't have any recommendations there.
>>>
>>>>Users can construct an arbitrary query from
>>>>large single table using query builder.
>>>>
>>>>Parametrized view cannot be used in this case since foxpro scans
>>>>the WHOLE BASE table, when query returns many rows and this takes
>>>>TOO long time. It is stange that Fetchsize parameter seems not
>>>>to work !? It must work with local views also ccording to fox doc.
>>>>
>>>>Linkmaster property requires that there must be a parent table and
>>>>existing index in child table.
>>>>I don't have a parent table (it is strange to create dummy one for
>>>>query). Also, for user-defined arbitrary filter contition it is not possible
>>>>to pre-determine reasonable index in child table.
>>>>
>>>>So it seems that there are no solution at all.
Andrus
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform