REFRESH(), REQUERY()

These functions let you update the data in views. Don’t confuse them with the methods of the same names. REFRESH() updates one or more records in a view with the current data from the original data source. REQUERY() updates an entire view—if it’s parameterized, it may prompt for new parameters as well.

Usage

nRefreshCount = REFRESH( [ nNumToRefresh [, nStartOffset
                         [, cAlias | nWorkArea ] ] ] )

REFRESH() lets you update just the records you’re working on with the current data from the source tables. You can use it on both local and remote views. If nothing has changed in the view, you simply get updated data from the source for the specified records.

The interactions between changes made to the view and changes others make to the original data are tricky. If you’ve changed the data, the changes are sent to the source only if you’re using row buffering (the default for views) and you refresh multiple records. In that case, it’s actually the movement of the record pointer that sends the changes. The rest of the time, if you’ve changed the data, your changes are sent and changes in the original data don’t update the view.

The second parameter nStartOffset is incredibly confusing. It behaves as we’ve documented it above (and it’s documented to behave that way in Help)—we can’t figure who designed it to be this way, though. Passing a negative value for nStartOffset makes it start with the current record. Passing a positive value makes it go backward that number (or to the beginning of the view) and start there. We suggest you don’t use nStartOffset.

Example

* This code might be in the Click event of an Edit button
* so the user sees the most current information
* before editing:
=REFRESH()
ThisForm.Refresh()

Usage

nResult = REQUERY( [ cAlias | nWorkArea ] )

REQUERY()’s role is also to update the data in a view, but it tackles the whole view at once. It also has a special role when dealing with parameterized views.

When you REQUERY() a parameterized view, you get a chance to change the parameters. If the parameters exist as variables, the new values are simply passed to the source and used in the query to determine which records to send along. If the parameters don’t exist, the View Parameter dialog appears (once for each parameter), asking for a value.

As with REFRESH(), the handling of updated values differs based on the type of buffering used. With row buffering, the REQUERY() call moves the record pointer, sending changes to the source. With table buffering, you have to explicitly commit or revert changes before you can REQUERY(). Attempting to REQUERY() a view with changes in the buffer generates an error.

In both cases, changes to the source data are reflected in the view following REQUERY().

Example

* Assume you have a view of the TasTrade employee table
* parameterized on Title (job description) with a parameter
* called cTitle. To change the open view to look at all the
* Sales Reps, you could:
cTitle = "Sales Representative"
=REQUERY()

See Also

Create SQL View, CursorSetProp(), Refresh, Requery, Use