>>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?

Emanuele,
It might be considered as a bug just for it returns .T. even if the table buffer was used. Other than that it's true.
What you want to do is impossible doing a seek, indexseek, keymatch or whatever when buffered tables + multiuser is in question. You should do it via another procedure like GetNextId in solution.app using intermediate tables or other means like GUID generation.
Cetin