Jim

>I am not depending on the messagebox to monitor what is going on. I inserted that code defensively in cases when i wasn't running this under the debugger. With the debugger, I am actually displaying the value contained in the SEEK argument in the Watch window.

I only mentioned that because it's easy to get a mindset about what you think is going on, but the diagnostic outputs a different thing.

>In answer to your other question: the treeview key value is the value of the LOCID + '_', and I am monitoring that in the watch window, as well as val(THISFORM.NodeX.Key) to confirm that it is returning the correct LocID.

What happens if you replace this code:

SET ORDER TO LOCTREEID
llResult = SEEK(VAL(THISFORM.oNodeX.Key))
nRecord = RECNO() && for debugging purposes

with this:

llResult = indexseek( int( val( THISFORM.oNodeX.Key ) ), .t., THISFORM.cDBFname, "loctreeid" )
nRecord = recno( THISFORM.cDBFname )

I find it just a lot less code you use the indexseek() and seek() functions with the additional arguments rather than having to "perturb" the table current order.

>The thing that is odd here is that the SEEK() works correctly the first time, but not the second time. It returns .T., but sets the record pointer to record #1.
>
>Again, note that LocID is an integer, not string. The seek shouldn't be confused by things like spaces or extra decimal places.

Sorry I was focused on the str() involved in the composit index.

>I have tried deleting the CDX file, and then recreating it. That didn't fix anything.

So that rules out index corruption.

I notice you keep USEing the dbf inside the drag drop is that really necessary? Where are you closing the table? What record are you ending up on? That might help you figure out what is wrong.