That's not entirely true. With VB or Access it would still be slower than SELECTS and Filters. However, there's no way I'd not use SQL anymore. Try to build a grid with relations between a parent table and a lookup table. Now resort it on a column from the lookup table. Once you see how hard that is compared to the SQL version, and realize you could use SQL to produce all cursors - and that means you only use SEEK for the heftier data processing chunks of the application, you may find things go together much easier.

Maybe it's the yankee in me. My projects used to use grids to offer parent / child list relations.Before that the projects also allowed entry at grid cells. Then they became just navigators that set "unbound" textboxes for edit. Now the projects use OCX [exclusively] for the navigation. Does all the classic stuff like selecting a different parent and then re-populating one [or more] child lists. Even some find the parent from the child - or reverse look ups.

There seems to be a lot less flicker if the data is scaned directly from the DBF to the OCX. Even the small moment it takes to complete a cursor cycle, even for a small (or empty) data set can be noticable if we "look" for it. M$ may improve the VFP grid. The OCX have "live" sliders. The grid is still snap to (i think). But still if projects are just using the list to navigate why deal with the overhead in a grid. Select a row on an OCX and you read the index. Select a row on a grid, you have the all the housekeeping associated with an afterrowcolchange (is it a only a column change, or is it a row change).

The column sort on OCX is cool too!

Granted, with ocx, when edit values are written back, the update requires a "literal" transaction with the object, rather than a refresh and a setfocus; but, once those little OCX data handlers are tuned, they scream (and they look good doing it)!

It's always about the "flicker" - isn't it?:-)

OCX gets me so hot! pzzzzzzz......