I know that is the work-around for the issue: open all views NODATA and requery them elsewhere. Of course 90% of them are opened NODATA anyway, but the lookup tables and any tables needed to initialize controls I've usually opened with data. These typically have few records but that doesn't seem to matter--even 1 is too many. I ran into an issue yesterday when trying to implement this "work-around" though: Some of the views with data are opened with the NOUPDATE clause and that prevents me from using REQUERY elsewhere. I can use a different method to prevent updates but by the time I've had to issue multiple additional commands, I've lost the performance advantage gained from using the connection handle. It looks like a no-win situation at this point.

I noticed that the SQL properties you mentioned yesterday are all set to their default values. The only one I have changed in this app is DispLogin and I don't see how that could cause this behavior. In effect, the USE command operates asynchronously. You can deal with that if you know that's how it works--undocumented fact though it is--but I'm worried about how many other commands might behave this way. Is this a dangerous thing to do (use the connection handle to open views)?

Here's a bit more info on the issue: It isn't just the USE command that behaves asynchronously, maybe it is all commands in the DE. IOW, you can't requery there without causing the same Connection Busy message. I'm wondering what the event sequence is. It is documented for AutoOpenTables = .t. but just were does the DE.OpenTables() event occur in that sequence? Is it where the cursor init would be? If so, there is no way to requery the tables needed by the object init in time since that event before the form load. Seems to be a bit of a catch 22.