>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. Now couple of things I'm curious to know, if someone has already tested them: - what's the speed of using again (network etc) - how do the (updatable) views behave in this case, can they be Used Again, and is there any significan overhead, or obstacles or whatever - if a view is used again, it probably doesn't contain records from the first Use's buffers, right? If these are no much problem, it seems to be the way to go.