>>I enter 'my location' on a row. I care its existence only and only if exists on another row. Do an indexseek(), get .f. and let the pointer move off the record. If it returned .t. I had to check if the founded record was the record I already inserted or not (and I did that in past thinking why I can't do that in an easier way).
>>When I move off the record and do an indexseek() for 'my location' it would return .t. and I wouldn't let the record with that value.
>>However there is still a problem ;
>>I'm doing inserts w/o moving off the record at all and might end up by inserting multiple 'my location'.
>>It's easily workaroundable :
>>if !indexseek(...) and mytable.myfield # 'my location'
>>This would behave as seek() except it wouldn't move the pointer.
>>Cetin
>
>Cetin, I think you've found a backdoor way to make lemonade out of lemons! <g>
>
>I'd still prefer the function behavior matched that of SEEK and KEYMATCH. After all, Ken and the team did give us a way to use INDEXSEEK with the second parameter to control whether or not the record pointer moves or not.
>
>And, BTW, I wouldn't count on that behavior for the long term, judging from Jim Saunder's response to my bug report.

OK Ray,
Sounds it'll be 'fixed' :)
Hmm I should call Jim not to fix that way :) Kidding I almost have no code relying on indexseek.
Cetin