Since you are certain that John missed, any chance the error is in the code eliminated by simplifying?

I would exchange the select/append/gather to one "insert into mycursor2 from name " if it cannot be done in 1 SQL for the whole cursor, but that should not cause any error.

Instead of try/catch I would implement some logging to get an idea if there is a certain pattern of the error coming up - esp. if the scanned cursor has any order set. In the logging call reflect at least 1 value, reccount(), recno(), bof(), eof() order() of all cursors relevant.

Creating a cursor in a tight loop should not be a problem, but in vfp8 and earlier closing a table and subsequently opening it again gave spurios errors. This happened very sporadic (only after a few million calls), but I ran into it: Aleksey fixed it for vfp9 (even if most people never encountered the error more than once at most) , but something similar might happen in your code. I'd add explicit closing of mycursor2 (as from code it seems to be throw-away) as well, perhaps with a few doevents sprinkled in and dynamic names referenced via (lcCursor2Name).


>I have in my scan...endscan procedure an error 'File is not open'
>The error occurs on line endscan
>procedure (simplified)
>

>select myCursor
>scan
>   if llCondition 
>      create cursor myCursor2  (field1 i, field2 m)
>      select myCursor
>      scatter name m.loCursor2 memo
>      Select myCursor2
>      Append Blank
>      Gather Name m.loCursor2 Memo
>      select myCursor
>   endif
>endscan
>

>
>debugger shows that on start and on end myCursor = alias() also myCursor2 is correctly populated with content of myCursor
>where should I put a try...catch to catch this error?
>
>Regards,
>Koen