>>I only recommend REQUERY() because I know exactly what it does. The documentation for REFRESH() implies that it runs the entire query as well, but only applies the changes for the specified rows.
>
>>REFRESH() is not faster than REQUERY, and I have never had a need to prevent the updating of other rows, so I never use it. From what I gather nobody else does either.
>
>=REFRESH( 1 ) SEEMS substanially faster than =REQUERY()....and I'm only running on my system; the client will be on a network.
>
>
>>Does it work with REQUERY()?
>yep
>
>I think maybe I was heading off in the wrong directions...now I'm wondering if I even have to do a REFRESH/REQUERY where I'm doing it....here, in general, is what I'm trying to do.
>
>The underlying tables are PEOPLE (name, DOB, gender etc. and 2 ethnicity codes), and ETHNICITYDEFS (w/code and description). I have a view that displays fields from PEOPLE and description of ethnicitys from ETHNICITYDEFS.
>
>User clicks on NEW button and I do an INSERT INTO the view and input controls are enabled
> OR
>User clicks on EDIT button and input controls are enabled
>
>Control sources of input controls are columns in the view (underlying tables are not referred to anywhere, except in the view).
>
>User makes changes and clicks on SAVE. After appropriate checks, I issue a TableUpdate (or TableRevert)...looks like then all I have to do is a GRID refresh????
>

What is being dsiplayed in the grid? What cursor is it based on? The view described above? If so, then, yes, all oyu have to do is refresh it.

>DO I have to requery the view at this point? I just tried it and doesn't look like it - for either new records, edited records or deleted records....is the above a "correct" way to deal w/updateable views? (guess I'm still learning about how to use them).

You shouldn't have to Refresh() or Requery at this point.