>>If you can use a debugger, set a watch expression on SELECT("Main_Cursor") and put a Set Step On in form's .load(), then it should stop twice: once the cursor is created (it would show a non-zero value) and next when it's closed (becomes zero).
>
>Unfortunately, I tried this approach. And I never get the cursor closed on my system, during testing.
>This happens to some customers. And mostly in a couple of methods where the code "determines" that the cursor is closed. So the cursor gets closed in a method before the one where the error occurs.
>I will have to place many test codes - checking if the cursor is closed - at design time. And maybe this will catch the problem. I suspect, but I can't prove, that the cursor is closed because something happens to the desktop.
>Although I don't know for sure.

A few general things to consider:

- If you're using multiple datasessions, are you unexpectedly switching between them?
- Are you implicitly closing your table by opening another one in its work area - maybe you're forgetting an "... IN 0" clause in a USE command or something similar?
- Are users selecting an unexpected work area by clicking on a grid or some other control?

I use defensive coding like this when opening tables, running SELECTs or doing other data munging:

FUNCTION MyFunc
LPARAMETERS ...

LOCAL lnSelect
lnSelect = SELECT( 0 )

* Data munging goes here...

SELECT ( lnSelect )

RETURN

Another defensive technique is to ensure a table is open before doing anything which requires it - if not, open it. This doesn't pinpoint why a table is being closed unexpectedly but minimizes the impact of that happening.