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.