Jim...

Do you believe everything you read? Far less overhead? In terms of what, the client or the server? As one who is quick to criticize documentation, I am surprised you are taking a strict interpretation of what you are reading. Let me ask you, since I don't have my copy yet, what was the rationale for the strong recomendation? Certainly, keeping connections around smacks in the face of a stateless environment. This is why we have connection pooling. As a hard and fast rule, I tend to disagree with what the book states.


Generally, it is a good idea to drop your connections when you don't need them. Obviously, if you need a connection, you should get one. And, you should keep it around as long as you need it. There are no hard and fast rules here, only guidelines.





>John,
>
>I am only approx. 125 pages into the 800+ page "Inside SQL Server 7.0" book but in there it is rather forcefully recommended that a connection be left in place as long as any other work is expected to come along, even if that is projected to be a long time away. Far less overhead, they say.
>
>Jim N
>
>PS That would be applicable to the *real* system and would have nothing to do with the MSDE shipped with Access 2000 or Office 2000.
>
>
>
>>>Usually, when we write an application, we connect to a remote datasource when
>>>user starts an application and disconnect when user finishes. Otherwise, we'll >get a perfomance problem. Do you think it reasonable to connect just before >updates, deletes, inserts, and queries and disconnect immediately after?
>>
>>Sure. Why should your server maintain the overhead for a connection that is idle. This is one of the features of MTS, the ability to pool connections. Even if you don't use MTS, there is still a benefit in only connecting when you need to update/fetch data.