>It is brute force and not elegant. If you know a command you're issuing is causing the problem, one would like to think it would be possible to "clean up after oneself" rather than relying on brute force.

The pooling is what gives performance. The connections remain active and are using. If I close them in and out, at 2000 SQL Server hits per second, it would probably create some performance benchmark which would be a little bit lower than actual.

>Are there any additional parameters to your data fill command such as CloseConnectionWhenDone? What about the connection you're using for that - anything like DontPoolThisConnection, or manual connection handling that would prevent pooling? Are you making new connections (even if they're pooled) for each operation or are you using a global connection which has been defined higher in the call stack?

The code you saw is what it is. On the first hit, this is by default to leave them open, as per our the data provider works with the backend. We could try to take a look at closing that at each request. But, it will not perform as good.