>> One thing I wanted to try with this is to hide the 7th table and see if Cursor7 would be the one giving the error. Do this on something that otherwise works, so I'd know it's regularly detecting the introduced error.
>
>It is not a first table. I used some of tables exclusively in
>other vfp command window. In DE Error event, no one table is opened!

Makes me wonder how does this really work, is it checking something internally and then immediately closing all tables if one is not accessible, or what? I never really understood the internal works of the DE, what does it really do. The "does an internal equivalent of USE (AGAIN)" and similar explanations are simply not enough.

I'm on this subject for two reasons: first, I have a similar problem sometimes in development (someone using VFP to take a look into some tables, and since nobody bothers to put exclusive=off into config.fpw, they lock out), and second - I thought I had some idea how this could be done. Now if I get to steal some time I may do some tests myself.

>>Another thing to try - check if any of these tables can be USEd while still in the error method, and see what error you get if you try.

And this would be the test - just hide one of the tables (not the first one) and see what will happen in the error method. It'd be also interesting to see if any of cursor.error methods would fire.

>It seems simpler to set autoopentables .f. , loop
>through DE cursors in Form Load event and open them manually.
>I dont use any DE events. It this exactly the same as letting
>form itself to open all tables ?

Nearly same - you still design it in the DE designer, and have all the table/cursor properties set in advance, and have the cursor and relation objects (so you can manipulate some of their properties later at runtime, but you can do that with xBase functions and/or SET stuff on the alias). Other than that, that's it.