Thanks, Bob and Glenn. This is great info. Thanks to Glenn for being very specific about how I would populate existing local cursors with new data retrieved from SQL as needed.

What I gather from this discussion is that I'm basically on the right track when I imagine substituting R-W cursors for my current local tables and relations. The data bindings and the look and feel of the forms would remain much the same.

Glad to hear that VFP 7 will make a R-W cursor just for the asking.

I'm quite aware that I don't want to promise the user that they can browse entire tables. What _is_ useful is the feature they now have of browsing a small subset of data which has been predefined in a Search screen. I do this now by creating a cursor of primary keys so that PageDown means get the record pointed to by the next primary key.

What I imagine doing is simply an elaboration of what we have discussed. Instead of one OWNERS record, I have N records where 1 <= N <= ~1000. We are usually talking less than 100 records here. Then I would retrieve the records from the other tables getting children to any of the OWNERS records. (If I were doing this in VFP I would be using 'IN (SUBQUERY)' to select the child records. Not sure about MySQL.)

In this case (with mulitple OWNERS records) I imagine I would want to set up relations between the local cursors. As I said, that worked fine in my sample code so I assume there is no barrier here.

Now the user can PageUp/PageDown within the populated c_OWNERS cursor with the child records changing automatically according to the relationships.

Actually now that I think about this, I realize I don't even have to change my current approach. Just keep the cursor of primary keys and retrieve one OWNERS record and associated children at a time. I assume that the SQL connection and retrieval for these very small sets would be so fast that the user would not notice. In fact I realize further that this approach would be much more appropriate for the occasional dial-up connection than downloading 100's and possibly 1000's of records at a time. "Small is Beautiful."

I've been talking about OWNERS but actually I have three of these important tables with two main forms and associated children for each:

OWNERS Search Srceen -- OWNERS Update Screen
ACCNTS Search Screen -- ACCNTS Update Screen
RESERV Search Screen -- RESERV Update Screen

I'm encouraged. There is a lot to resolve before I head down this road but it looks very promising to me.

Thanks, again.

Peter


P.S.
One last thing: are either of you using a commercial framework with this approach?