>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