You said: "If you switch to connection pooling you don't have to change much in your application. Basically you need to make sure that a connection is closed when it's not needed. Instead of storing the handle returned by SQLCONNECT() in a property and reusing it permanently, your classes would need to issue SQLCONNECT() for every transaction."

The original problem that prompted this question was traced to an anti-virus scan that slowed things down so much on Terminal Server that the remote view's normal attempt to reconnect to SQL timed out. However, connection pooling seems like an interesting concept and I'd like to understand whether it offers any value when used with remote views. I'm currently working on a form that has 15 to 20 remote views--all of them parameterized. Updates and requeries occur frequently and in multiple methods in response to the user's actions. The entire process is highly interactive. The form needs a connection to SQL for the entire time it is loaded in order for the remote views to function (AFAIK, you can't manually reconnect a remote view once the connection is lost/severed without losing unsaved data.) I could see establishing a connection as the form loads, and disconnecting when it unloads but that doesn't help prevent connections from timing out. The user might work with a specific form for an hour or more--or worse yet, minimize it and go off and do other things for a while, expecting it to be waiting patiently when they come back. What impact does would this have upon performance? What about Curval() and Oldval()? Bottom line: has anyone done this with remote views?