Yes, Buffering mode is 3 for SPT cursors. But I use them a lot and didn't have any problems with their indexes.
Instead of copy and then reopen you can do:

lcfile=sys(2015)
lnresult=sqlexec(osystem.ncomhandle,lcPOCostSQL,lcfile)
SELECT * FROM (lcfile) INTO CURSOR CurLCosts
SELECT CurLCosts && Buffering mode = 1
INDEX ON citemno TAG xcitemno
...

>Hi Borislav,
>
>In the meantime.. I had a hunch that it might have something to do with the fact that it is a buffered cursor. I think that the buffering was 3 on it, which I think should be OK for indexing.
>
>So the short of it is that I **THINK** I fixed the problem.
>
>I changed the code to:
>
>
>** begin code
>lcfile=sys(2015)
>lnresult=sqlexec(osystem.ncomhandle,lcPOCostSQL,'CurLCosts')
>copy to (lcfile)
>use in curlcosts
>select 0
>use (lcfile) alias curlcosts
>index on citemno tag xcitemno
>
>I just tested it once in runtime. It worked. I'd like to do a few more tests to 'reconfirm'.
>
>I am sort of hazy on this but.. I think that the buffering is 3 on curlcosts. I think that it should be OK to index it then? It didn't complain on the create index statement Even so, I thought that just in case there is an issue with an index on a buffered table I should take that out of the equation. So, I changed the code as above.. and it seems to be working now.
>
>My hunch is that I should look into the (possible) issues of indexes on buffered cursors and hopefully confirm that it is connected to that somehow?
>
>However, I do want to try out your code as well and see how that goes. I will let you know..
>
>In the meantime.. I am hoping for some confirmation on my notion about the buffering. If you have an answer/idea on that it would be appreciated.
>
>
>Thanks,
>David
>
>
>
>>>Thanks Borislav,
>>>
>>>I will try the changes you suggestged and let you know.
>>>
>>>In the meantime, What is your thinking on how you rewrote it? My thoughts are:
>>>1)I didn't test for lnresult=1, I have debugged it and know it doesn't fail.
>>>If it did, my cursor wouldn't get created and I wouldn't be able to run the rest of the code.
>> This is just a check for errors. That keeps your application not to bomb if something happens with connection.
>>
>>>2) I didn't explicitly select curlcosts. **Normally** after the spt cursor is created the alias is selected. But...
>>Normaly yes, but i prefer to know what I indexed.
>>
>>>3)Is the statement seek ___ in ___ order ___ with a found() be better for some reason than the seek function()
>>I read about some bugs in SEEK() function or in IndexSeek (I am not sure) so I tend to use SEEK ... IN ... instead of SEEK() or INDEXSEEK(). They maybe are already fixed, but...
>>
>>>4)I tend to use do while loops - just a habit from about 20 yrs ago. Should the scan loop instead of do while operate differently?
>>Yes, it is faster (at least I think so, never made some tests). No need of SKIP, No need to SELECT cursor before ENDDO, and have less line of code :o)
>>
>>
>>>
>>>>WHat happens with this code:
>>>>

>>>>lnresult=sqlexec(osystem.ncomhandle,lcPOCostSQL,'CurLCosts')
>>>>IF lnresult > 0
>>>>   SELECT CurLCosts
>>>>   index on citemno tag xcitemno
>>>>
>>>>   select curreport
>>>>   SCAN
>>>>     SEEK curreport.citemno IN CurlCosts ORDER xcitemno
>>>>     IF FOUND([CurlCosts])
>>>>        replace nucst  with curlcosts.nucst,;
>>>>                nulcst with curlcosts.nlucst in curreport
>>>>     ELSE
>>>>        replace curreport.nucst with curreport.ncost in curreport
>>>>     ENDIF
>>>>  ENDSCAN
>>>>ELSE
>>>>   AEEROR(laError)
>>>>   MessageBox(laError[1,2])
>>>>ENDIF
>>>>

>>>>
>>>>>I tested this some more and can reproduce consistently. When running through the debugger the seek succeeds, when running through runtime, the seek fails. I have the wait window 'no landed cost' in there now.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I am getting inconsistent results on a report, against the same data. When I ran my report through vfp runtime I got one set of data. When I ran it through the VFP debugger, I got a different result. I am wondering whether the execution delay of the debugger is what solved the problem.
>>>>>>
>>>>>>I create a sqlpass through cursor. Then I index it. Then I do a loop that has a seek that utilizes the index. In the code below, originally I didn't have the wait window 'no landed cost', so I don't know if the seek was failing. I alos didn't have the 'Please wait to see if this helps' wait window.
>>>>>>
>>>>>>The short of it is that I **THINK** that the seek didn't find the records it should have in curlcosts, because at the end of processing the loop, nlucst was 0.
>>>>>>
>>>>>>When I put the wait window 'Please waiting to see if this helps'. Then the seek succeeded.
>>>>>>
>>>>>>Is it even remotely possible that even though VFP moves on past the index on statement, when there is no wait window, that the index is not fully written? It's not that the seek line actually fails... there is no error message, it's just that when done, nlucst is 0, and I'm INFERRING that the seek failed. (I didn't have the other wait window in place before)
>>>>>>
>>>>>>This seems to be an intermittent problem. So it's hard to debug.
>>>>>>
>>>>>>
>>>>>>lnresult=sqlexec(osystem.ncomhandle,lcPOCostSQL,'CurLCosts')
>>>>>>index on citemno tag xcitemno
>>>>>>WAIT WINDOW 'Please waiting see if this helps' TIMEOUT 4
>>>>>>
>>>>>>
>>>>>>
>>>>>>select curreport
>>>>>>go top in curreport
>>>>>>do while not eof('curreport')
>>>>>> if seek(curreport.citemno,'CurlCosts','xcitemno')
>>>>>> replace curreport.nucst with curlcosts.nucst in curreport
>>>>>> replace curreport.nulcst with curlcosts.nlucst in curreport
>>>>>> ELSE
>>>>>> *WAIT WINDOW 'no landed cost found for ' + curreport.citemno TIMEOUT .5
>>>>>> replace curreport.nucst with curreport.ncost in curreport
>>>>>> endif
>>>>>>
>>>>>> skip in curreport
>>>>>>enddo