>>does this. Another tip that has quickly become the 'right' way to do
>>things: all primary keys should be surrogate. That is, the ser should never
>>see them, and they should have no real world value.
>
>This solves the PK issue, but still there's lots of situations where
>natural key must be unique, and checked against the table before
>accepting user's input, or some other records in the table must be
>'visited' for any other reasons. Since we've discovered lately that
>KeyMatch moves the record pointer and restores it (well, I thought it
>didn't, but I was wrong), someone (Barbara?) suggested that the solution
>may be to Use the table Again under another alias, and do all the
>locomotion in it, not leaving the record in the buffer.

This has been my practice for validating Social Security numbers. (Well not really USE AGAIN, but using two aliases of the same table in the DE of the form that does the checking). It works well, and I notice very little if any effect in form load.
Supposedly using a table for the second (or third) time is much faster than the first use, but I have not found this to be significantly true. Many sources recommend that your application open all needed tables in the initialization of the app, so all DEs will effectively be using USE AGAIN, and forms will load faster. But my testing (private datasessions) showed only about a 15 percent improvement in form load in my more complex (read: use a lot of cursors) forms. This was just not worth the extra 20-25 seconds it took the app to load while opening 80+ tables.


> - how do the (updatable) views behave in this case, can they be Used

This one I have not tried, but I am curious to know as well.