Hi Mark ---

OK, there's where I misunderstood. I thought you were trying to use a single connection for everything. As far as a single connection for all views, you are going to run into performance problems with any size tables. And as to SPT...hmmm....it depends on the architecture. The connection is only important when you're grabbing data or saving it; it's not like you are continuously running data through the pipe. I have often used a single connection and ran all my SELECTs through it and all my updates through it as well.

>What might an alternative be? I'm thinking that by having 1 shared connection for my views & another connection (saved as a variable or appliction level property) for my SPT that the entire app can run on 2 connections. The only alternative (as I far I can see) is to establish a connection each time I want to use SPT which is probably inefficient. I would not manage the connection used by the views, I would let the views do that.
>
>>Hi Mark
>>
>>There might be a problem. How, for example, are you going to identify the open connection number for views to use SPT in? Secondly, if you have several large tables open, you risk a timeout or "out of memory" error.
>>
>>
>>>We are designing our SQL 7 implementation (while we are still learning it)& have decided on the following regarding connections. Our remote views will share connections & our SPT will use 1 connection that is opened up in the logon process. This 1 connection will remain open through out the appslication session. Are there any potential problems with this that anyone can see?