>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????

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).

Thanks for your help and any input....J