>>>>>>Hi,
>>>>>>
>>>>>>I have trapped (using Try / Catch) an error "File is not open" in the following section of the code:
>>>>>>
>>>>>>

>>>>>>IF SELECT("V_WO_NUM") > 0 
>>>>>>	SELECT V_WO_NUM
>>>>>>	INDEX ON FIELD1 TAG FIELD1
>>>>>>	INDEX ON FIELD2 TAG FIELD2
>>>>>>	INDEX ON FIELD3 TAG FIELD3
>>>>>>	INDEX ON FIELD4 TAG FIELD4
>>>>>>	INDEX ON FIELD5 TAG FIELD5
>>>>>>	INDEX ON FIELD6 TAG FIELD6
>>>>>>	SET ORDER TO TAG FIELD3
>>>>>>ENDIF 
>>>>>>

>>>>>>
>>>>>>Before the above code the cursor V_WO_NUM is created by SQL SELECT (getting data from a VFP table).
>>>>>>
>>>>>>What could possible be wrong with the above (not one time but almost every other day) that it causes the problem? And I could never duplicate this error on my PC.
>>>>>
>>>>>The SQL SELECT that creates the V_WO_NUM cursor may be creating a filtered result set rather than an actual cursor. IF that's the case the cursor will have no presence in the file system, so any attempt to INDEX it will fail.
>>>>>
>>>>>You can address this by adding NOFILTER to the end of the SELECT that creates the cursor. That will force the cursor to actually exist in cases where it otherwise might not.
>>>>>
>>>>>As for it happening on one machine but not another - ironically, it will tend to happen more often on machines that have more available RAM and other resources. It may also happen more often on machines working against smaller data sets or cursors.
>>>>
>>>>Actually I thought about the NOFILTER too but could not explain it to myself (as well as you did) logically. I will add the NOFILTER to my SQL Select. Can you think of how I can force the program on my computer to have this error? That is, is it possible for me to change my SQL Select (for testing) so that no cursor will be created?
>>>>Thank you!
>>>
>>>I don't know of any way to reliably cause a filtered result set. They *tend* to be caused by simple SELECTS from single tables, without any JOINS or complex WHERE clauses. Possible examples:
>>>

>>>SELECT * FROM SomeTable INTO CURSOR V_WO_NUM
>>>SELECT Col1, Col5 FROM SomeTable INTO CURSOR V_WO_NUM
>>>

>>>If you're purposely running your environment with low settings of SYS( 3050 ) you could try bumping them up to, say, 500000000 for both foreground and background. You could also try using smaller test data.
>>
>>Thank you very much. I am adding the NOFILTER to my SQL Select and start monitoring if the error on customer system repeats.
>
>It's a good idea to think of the NOFILTER clause as a "reliability" switch. If you're going to INDEX a cursor (or do certain other operations) then a file system presence is required for the cursor. In that case there is no performance loss by including NOFILTER.
>
>I find when I'm using standalone cursors I'm usually doing significant data munging so I need or want a file system presence. I tend to include NOFILTER by default in my SELECTs. There are probably some where I don't really need it, and I'm giving up a little performance, but for me reliability is more important.

I will keep this in mind. I am switching more and more customers to SQL Server database which makes this point of NOFILTER moot.
Thank you.