>I've specifically seen it when a double-buffered view added a record, and an INDEXSEEK() was issued against the base table, or another view of the base table, without that TABLEUPDATE() being applied. Realizing that the index file is not updated until the buffer is committed to the physical store here is the key; in the double-buffer. single TABLEUPDATE() model, the results of the change to the view are committed to the buffer of the underlying table; until that buffer is committed to the underlying table itself, it won't register as a hit on the index.
>

In a situation like that, sure, that's what I would expect. The thing that doesn't make sense here is that Wang is implying that it's the alias he's doing the INSERT INTO that isn't showing the new record. Plus, he says that a REINDEX will make that record appear, which certainly wouldn't be the case if it's a buffering issue. IOW, you'd still have to TABLEUPDATE to get the index to update (as you pointed out). I think there's more to this situation than we realize.

Wang, there's got to be something to this that you haven't told us. Is the cursor that you're adding the record to a view? If so, have you buffered the source table as well?