Mike,
In addition to Aleksey's suggestions, you should also make sure that MaxRecords = -1.

Typically, you'll get "Connection is busy" errors when the view is off "doing something" and another view attempts to use the same connection.

We've always traced these messages to a specific view that hasn't pulled back all its data when the initial query was run. Then later, something like a SCAN/RECCOUNT()/GO BOTTOM will force the view to go back to the dbc and retrieve more (or the rest) of the data. Until that point, however, that view "locks" the connection so that any other view sharing that connection receives the "connection is busy" message.

The only way (I've found) to track this down is get the connection handle of the view where you're receiving this message. Then, check every view using that connection, looking for the one that has SQLGETPROP("yourview", 'ConnectBusy') = .T. That will be the offending view. Fix that one, and all will be well again.

I've written a little prg (ConnectionSpy.prg) you can run when you get this message. It pops up a browse window with connections and the views that are (ab)using them. I can send it to you if you'd like.
---J

>Here is a little more info. The ENDSCAN instruction highlighted when the 'Connection Connect1 is busy' error may not have been a McGuffin after all. Tracing through the program and watching the SQL Profiler audit log in another window, I see that SQL Server is updating the underlying table when the record pointer of the VFP remote view changes. Makes sense, I guess. But I still can't figure out why that UPDATE command generates so many reads (over 16,000) or what exactly triggers the "connection is busy" error.