>>>>Hi All.
>>>>
>>>>I just want to gripe about the fact that filters and grids are still apparently a problem in VFP 6. I think it really stupid that I can open a large table and set a filter and browse brings up the data in seconds while a form with the same table in its data environment with the same filter and a grid connected to the same table takes minutes.
>>>>
>>>>And don't anyone tell me to use a view. I already know that and that is not the only answer to application development. If it was, the BROWSE command would never have been Rushmore aware and Rushmore optimization would never have been invented and LAN based applications would never have been made without a database server backend.
>>>>
>>>>Thanks
>>>>
>>>>Mike Yearwood, GE Capital Consulting
>>>
>>>Filter is actually not a problem but just a bad xbase habit. Grids themselves don't constitute any problems. I'm not going to tell you about views as you requested, but what about simple cursor? Also, there are other ways to speed up grids using UDF-ed columns pointing to lookup tables.
>>
>>I'll never agree that a filter is a bad habit. It's conceptually no different from a SQL where clause. Its only different from an implementation perspective.
>>
>>The simple cursor excludes the functionality of the views, so that's no good. The UDF-ed columns showing related data has some merit, but ultimately could result in a selection of all of the PK's from the data source and/or the data would be read-only in the UDF's which is also not acceptable.
>>
>>Am I the only one who is disappointed that we can't do with these new tools what Foxpro 2.6 could do so easily? We're not supposed to lose functionality as we improve. Imagine improving your car so you couldn't drive it as you'd like.
>>
>>Thanks
>>
>>Mike Yearwood, GE Capital Consulting
>
>You probably missed some points. Firstly, there is conceptual difference between filter and Select-SQL, just look at new NOFILTER clause which exemplifies the difference. Also, cursor doesn't exclude functionality of view completely: it's always up to you to bring data changes back to table programmatically, i.e. you will get some query speed at expense of some programming efforts. The last thing is that UDF column is read-only just from plain perspective. However, you can always make it editable doing your interface just a little bit more sophisticated (e.g. by applying right-click shortcut menus).


Actually, you are missing my points. A filter is conceptually (not specifics of implementation that you describe above) the same as a SELECT - SQL in that both result in subsets of data. Why should we write code to move data from a table to a cursor and back. That's supposed to be VFP's job (hence the tableupdate function and the various buffering modes). The real problem is that the filter is not fully/properly/completely (or whatever term you prefer) supported with a grid. This is indisputable. I think the best solution is to make a grid control that does use Rushmore and applies the concepts described by Tom Lewinson in Foxpro Advisor (August 1994) and updated by me in June 1997.

Can we begin a thread to spec out this new grid? I think that would address Victor's (I think it was him) complaint that I'm not contributing to the solution. The group of developers on this site can add value to this idea and address other problems with a grid. There are also other features that could be put in a grid (which is why so many other grids exist).

Thanks

Mike Yearwood, GE Capital Consulting