Hi Mark,
My point was that if you had multiple records displayed in a grid, CursorFill would not be a good way to go (since it destroys the cursor and builds a new one). However, as Larry mentioned, CursorRefresh works perfectly. You must call CursorFill initially, but thereafter, CursorRefresh works fine. Seems like the proper method name would have been called Requery, but I'll that what I can get.


>>I created a CursorAdapter Object last night. I had hoped it would work like a parameterized view--specify a few properties, call the CursorFill() and see the data--which it does. However, if I change a property or variable in the Select command, and reissue the CursorFill, the cursor is destroyed and a new one created. I had hoped the cursor would just repopulate in the background, not killing the cursor, as a parameterized view does.
>>So my question is, are my expectations reasonable? I guess if the Select command changed, of course, the cursor would have to be rebuilt.
>>I just wanted to build a cursor class that worked like a parameterized view on native tables, but didn't need a DBC. Looks like the CursorAdapter will almost do that.
>
>You can do that. In my SelectCmd property, my SQL is:
>
>select * from appusers where keyid=?nKeyID
>
>That command never changes. When I need a new record, I specify the value of the new nKeyID parameter, then issue:
>
>PRIVATE nKeyID
>nKeyID = somevalue
>THISFORM.DE.adpAppUsers.CursorFill(.f., .f.)
>THISFORM.REFRESH()