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

If you have that many hits/sec then you probably need to take careful measures for everything to work. As I see it you have 2 main approaches:

1. Graceful: work from the client side. Set a global flag e.g. "MaintenancePending". When that's set client apps stop trying to connect and users get some sort of "down for maintenance" message. Then clear existing connections (pooled or otherwise). Switching your data fill commands to non-pooled mode when the flag is set may help with this

2. Brute force: work from the server side. The second approach at http://dba.stackexchange.com/questions/43802/how-to-block-user-access-to-perform-database-application-update looks interesting (not tested by me). If you need to force disconnects it can be done but it ROLLBACKs the connections it closes, which is inelegant and may cause users to lose work