>Ray,
>Couldn't follow the whole thread but maybe not told yet :)
>We discussed this sometime ago. Indexseek() works on a buffered table BUT only returns .T. for a newly inserted row key as you move off the record. Whatever the type of buffering is (table or row) as soon as you move off the record indexseek() returns .t. Documentation is vague but I always got its purpose was this and not considered as a bug.
>As you move off the record even if the buffering is at table level you get Indexseek() .t. for that record. I think it's exactly what I would want indexseek() to do for me.
>Cetin


Well, thanks very much, Cetin, that finally sheds some light on the subject.

If you take my original code sample and modify the first INSERT block as follows:

FOR n = 1 TO 10
   INSERT INTO anytable (pkey,cchar) VALUES (n,'string')
   SKIP 

   IF !INDEXSEEK(n,.F.,'anytable','pkey') && same result with .T. or .F. in move record pointer parameter
      WAIT TRANSFORM(n) WINDOW && no record found ???? Why not?
   ENDIF
ENDFOR

INDEXSEEK returns .T., as expected.

Howerver, Cetin, I can't agree that this isn't a bug. If you look at my original sample code (first post of the thread), you'll see that SEEK and KEYMATCH behave as expected in all cases. There's no reason I can see that INDEXSEEK should behave differently. In fact, if I want to determine if a key value exists without moving the record pointer---the real intent of INDEXSEEK---it is the only way I can do it. And I sure as heck want it to work in all cases, whether I happen to be on that record at the time, or not. In fact, having to move the record pointer to get a function, whose purpose is to avoid moving the record pointer, to work correctly is a contradiction in terms.