I cannot be sure if all data readers and commands were manually disposed but I suspect so (it's been already some years since I debugged this). What I do know, as I have a mechanism in place to track of all open connections, is that when this problem appeared all opened connections had already been properly closed. I believe that it is part of the contract of IDbConnection.Close() that it should actually close the connection (when no pooling is active) and if some command or reader tries to execute it should fail. So the native connection staying open after being explicitly closed seems to me an undesirable behavior. Thank you for formally exposing the busy handler so that I can finally get rid of all the reflection stuff I had to use.