>Consider the code below .... if you have an indexed cursor with buffering and you want use indexseek to search for the indexed value field you must issue a go top on the table before use of indexseek else even if your value exist on table, the indexseek will return .f. anyway, if you don't use buffering (buffering = 1) you will haven't problems!
>
>Someone have an explanation for this behavior ?? Is A Bug ?

No - the index isn't updated until the data is committed from the buffer to the backing table - it's exactly the behavior expected. INDEXSEEK works against the backing data; you have no way to 'see' uncommitted data at other stations (or even in other datasessions of your running app that have not committed the data to the table). It's a matter of using the wrong command to do what you're trying to do.

The reason that 'go top' seems to fix things for you is that by moving the record pointer with record-buffering that commits the data when the record pointer changes is that your 'go top' commits the data - if you were using table buffering or allowed multiple uncommitted record changes to accumulate, 'go top' would not fix things. This ties in with the logic of needing to change buffer modes when generating or rebuilding indexes on views.