As Al suggested using SEEK with three arguments will assure indexes.

IF SEEK(lcTreeKey,"myTable","TREEORDER")
   * do the find.
endif

also check to make sure EXACT is ON/

Check through the debugger to assure the expected lookup key is the same as the actual lookup key.

Treeview may have issues with node keys that began with numeric characters. Maybe it was list view!


Is it possible you have duplicate records? Delete the tags. INDEX (not reindex) on your key fields again.

VFP usually des the right thing. Check to make sure what that the point asked for is the point actually asked for:)

>I'm working with a table that has two indices for it. Oneprimary index using a numeric field, LocID. Let's call this index LOCID.
>
>The second index is a composite equal to a combination of two fields, like so: STR(ParentID)+STR(ChildOrder). Call this index TREEORDER.
>
>This table is used to populate a TreeView control, where the ParentID is the LocID of the parent of this child node, and the ChildOrder is a number that is used to put the children of a node into the correct order.
>
>When I am populating the TreeView control, I SET ORDER TO TREEORDER.
>
>In any case, I'm working on a Drag&Drop function that allows me to move nodes around. At no time do I change the LocID of any record.
>
>What is odd, is that at times I can SET ORDER TO LOCID, and SEEK()for a certain value. The result is .T., and the record pointer is on the correct record. Later, I can do that same thing, SET ORDER TO LOCID, and do the same SEEK(). It again returns .T., but the record pointer is on Record #1, the wrong record!
>
>I don't see how this is possible if I never change the value of LocID for any records?
>
>This is driving me crazy. I would appreciate help!
>
>Thanks,
>Jim