>>It's known and intended behaviour, no bug. It's primary usage is to check for existence of key during a new record insertion. If it returned .t. for your newly inserted record then you'd be doing old workarounds to check. Once you move off the record indexseek would return .t. for the newly inserted record regardless of it was row or table buffered.
>
>
>I think that isn't a good behavior ... if i want to introduce a code that must be unique and i want to be proactive, i test the existance of code -'CODE1'- before inserting record, now i introduce a second code (without moving record pointer) -'CODE1'- that is the same of the first one (caused by my amnesia 8-)), i test the existance of code, indexseek return .f. ... so i insert the record ..... my primary key emit an error ..... isn't true?

Only on the second record - the first commits. You can complicate this by having a third addition "in process" at another station, completely unaware of the two from your station. First one to the punch wins.

The solutions is that INDEXSEEK() is not a reliable mechanism to do what you want to do - it's not a bug, it's a flaw in your choice of INDEXSEEK(), since it can only see what's been committed, not what may be pending application to the backing store.