All that I can say, John, is that their rationale made a lot of sense to me. Essentially the 'overhead' is minimal and no connection is forever "tied" to a single thread/fiber/processor/whatever.

Yes, I am quick to criticize VFP documentation, because it warrants such criticism and I believe that countless have also said so right here.

So does that mean that I should crap on all documentation, just because it is documentation??? And, in the case of "Inside SQL Server 7.0" it is not a part of the product documentation.

Things change, John, and maybe in this case SQL Server's method of handling connections has changed. Check it out and decide for yourself.

Even "experts" are known to not always be correct on everything. We won't ask that your blue envelope be rescinded if you are incorrect here, even though you might in other (well known) cases.

Cheers,

Jim N

>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.