>>I thought connection pooling was the default behaviour for ADO.NET (and, IIRC, the default number of connections is 100).
>>I also thought that you wouldn't get the problem if you were *not* using a connection pool since in that case there is no limit (except memory limits) on the number of connections.
>>
>>To me it sounds as if you *are* using connection pooling but, somewhere, not closing a connection and thus ending up with a 'connection leak'......
>
>So, even if the setting for the connection pool is not defined in the connection string, the fact that we use ADO.NET is enabling the connection pool. But, I am wondering why they put so much emphasis on it if it is by default enabled.
>
>I assume there is probably some default we could change from ADO.NET in regards to the connection pool setting. Thus, I would probably have to look at that to see if something could help.

I think Neil may have posted this link before but read this through:
http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx

The connection string values that affect pooling are:
Connection Lifetime
Enlist
Max Pool Size
Min Pool Size
Pooling

The last one dictates whether ADO.NET uses pooling. If you are not explicitly setting it to 'false' in your connection string then pooling is enabled and used.

Can you monitor the open connection count on the server?