>>I code defensively and rely on good architecture and testing to facilitate the creation of robust solutions - however, I cannot guarantee that I will catch 100% of the possible errors. Hence the need for ON ERROR and TRY ... CATCH. When the Open Dialog appears I am no longer in control, to think anything else is a case of being 'economical with the truth'.
>
>I never get "Open Dialogs" ...
>
>My idea of coding defensively is to open EVERY table (required by a given "process" in a "session" object), and acquire all necessary table / record locks explicitly at the START of every "task / process / transaction" to insure that process has the highest probability of running to completion; virtually all "file" type problems are caught at this point and can be handled via an error routine. And no keeping the User "in suspense".
>
>Running a process and opening files, "as we go along", is a little too risky for me and means I have to spend a lot more time thinking about back-out / recovery procedures.
>
>All "process tables" are subsequently flushed and closed at the end of a process.

I agree completely and I too have never observed any "Open Dialogs" in a production system. However I need to emphasize that "have never" is past tense, I cannot guarantee that in the future one will not appear - since this functionality is merely latent.

With regard to verifying the presence and opening all persistent tables - I am with you. I was thinking more along the lines of a SQL Select from a runtime created cursor. Any example that demonstrates this would necessarily be contrived, but cannot be completely ruled out.