The app is a web server and I have no idea of the sequence that produces it. The problem is extremely rare and I have no reports from the field about it. I observed the error an internal test server. Perhaps your mind reading would be improved by reading the message title.

>>Of course it is not real code,
>
>Silly me. My mind reading is on the fritz this weekend. Something about a backhoe. It sounded to me as if you just wanted to ignore the error. Didn't realize you're trying to diagnose it.
>
>> it is a simple example of a way to generate the error. I want to trap the error. What I do not want is a dialog box poping up and blocking the operation of an unattended process. ON ERROR does not fire unless a user intervenes and responds to the dialog.
>
>You're right of course that ON ERROR won't fire, which just means that I'll stand even firmer in my first suggestion.
>
>I gather you don't know where in the code this is happening or you'd be able to put in preventative code as I suggest, and so thus your idea to trap the situation.
>
>Have you an idea of what table is being looked for that's not open? For example, cancel the find dialog and see what table the resulting error refers to. In that case, you can put a watch point on USED('MyTable') = .F. Otherwise, you'll need to look for places where you assume a table is opened. Perhaps you've recently changed a form to be a private datasession? Or one form is calling another form that is closing the tables.
>
>As for trapping the situation...You can only do that by checking USED(), for example, which is apparently the cart before the horse.