I have this 'issue' since a long time and I am really wondering if this is just me or if there actually is a way of preventing the following:
UPDATED
In Visual Studio, when using the Server Explorer on a .mdf database, in a Entity Framework Code first approach project whenever I am opening the Database manually to see the data of certain tables (clicking on Show table data), it seems that even when I close the connection like this:
the database connection stays open somehow in the background.
I am getting "... the Database is currently in use ..." error if wanting to debug afterwards, after closing the connection, even when restarting the solution.
When I close all sqlservr.exe process(es) in the Task manager that does the trick.
Note that this is a local solution and a local database (.mdf) i am using for testing purposes. Nothing or no one else is using this solution.
I am quite sure this is not the behavior it should have right?
What am I doing wrong or what can I do to not have this behavior if this is not by default?
Thank you in advance for any feedback!
Include the "Pooling" flag in the connect string set to false:
Pooling=False
However, this might not be the best option in a productive environment:
Connection pooling reduces the number of times that new connections must be opened. The pooler maintains ownership of the physical connection. It manages connections by keeping alive a set of active connections for each given connection configuration. Whenever a user calls Open on a connection, the pooler looks for an available connection in the pool. If a pooled connection is available, it returns it to the caller instead of opening a new connection. When the application calls Close on the connection, the pooler returns it to the pooled set of active connections instead of closing it. Once the connection is returned to the pool, it is ready to be reused on the next Open call. (...) SQL Server Connection Pooling (ADO.NET)
Related
We are experiencing what I believe to be an issue with connection pooling when using Amazon RDS database instances to back our web application running on ECS.
Using https://github.com/npgsql/Npgsql.EntityFrameworkCore.PostgreSQL ("Npgsql.EntityFrameworkCore.PostgreSQL": "1.1.0").
The error specifically occurs when we roll-back the RDS instance to a previous point in time. The connection string remains unchanged, but I suspect the Npgsql driver believes it still has active connections open, even though they have been terminated server side (by the rollback).
Restarting our application obviously fixes the problem as it creates new connections after launch, but is an undesirable solution.
Is this a bug within Npgsql? Should it be timing out on a connection that has been forcibly closed? Maybe there is something we can put in the connection string to force it to retry? (Although I'd like to avoid turning off connection pooling completely if possible.)
i am using sql server 2012 with desktop application as client , the application get errors after period of time when no activity on it , i googled about this issue all solutions points me to AUTO_CLOSE option on database but it's already set to false .
i thing is something missing in connection string (ADO Extension)
To be honest, if you have long running connections, you can hit these errors regardless due to firewalls / routers closing connections, etc. The correct solution is to instantiate a connection when you need it, use the connection and release it. With connection pooling, this is not really a performance problem.
If your long-running application is "bursty", it is sometimes convenient to open the connection, do a number of commands -- then when you go idle, release the connection and wait the next burst of activity.
I have 3 servers set up for SQL mirroring and automatic failover using a witness server. This works as expected.
Now my application that connects to the database, seems to have a problem when a failover occurs - I need to manually intervene and change connection strings for it to connect again.
The best solution I've found so far involves using Failover Partner parameter of the connection string, however it's neither intuitive nor complete: Data Source="Mirror";Failover Partner="Principal" found here.
From the example in the blog above (scenario #3) when the first failover occurs, and principal (failover partner) is unavailable, data source is used instead (which is the new principal). If it fails again (and I only tried within a limited period), it then comes up with an error message. This happens because the connection string is cached, so until this is refreshed, it will keep coming out with an error (it seems connection string refreshes ~5 mins after it encounters an error). If after failover I swap data source and failover partner, I will have one more silent failover again.
Is there a way to achieve fully automatic failover for applications that use mirroring databases too (without ever seeing the error)?
I can see potential workarounds using custom scripts that would poll currently active database node name and adjust connection string accordingly, however it seems like an overkill at the moment.
Read the blog post here
http://blogs.msdn.com/b/spike/archive/2010/12/15/running-a-database-mirror-setup-with-the-sqlbrowser-service-off-may-produce-unexpected-results.aspx
It explains what is happening, the failover partner is actually being read from the sql server not from your config. Run the query in that post to find out what is actually being used as the failover server. It will probably be a machine name that is not discoverable from where your client is running.
You can clear the application pool in the case a failover has happened. Not very nice I know ;-)
// ClearAllPools resets (or empties) the connection pool.
// If there are connections in use at the time of the call,
// they are marked appropriately and will be discarded
// (instead of being returned to the pool) when Close is called on them.
System.Data.SqlClient.SqlConnection.ClearAllPools();
We use it when we change an underlying server via SQL Server alias, to enforce a "refresh" of the server name.
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.clearallpools.aspx
The solution is to turn connection pooling off Pooling="false"
Whilst this has minimal impact on small applications, I haven't tested it with applications that receive hundreds of requests per minute (or more) and not sure what the implications are. Anyone care to comment?
Try this connectionString:
connectionString="Data Source=[MSSQLPrincipalServerIP,MSSQLPORT];Failover Partner=[MSSQLMirrorServerIP,MSSQLPORT];Initial Catalog=DatabaseName;Persist Security Info=True;User Id=userName; Password=userPassword.; Connection Timeout=15;"
If you are using .net development, you can try to use ObjAdoDBLib or PigSQLSrvLib and PigSQLSrvCoreLib, and the code will become simple.
Example code:
New object
ObjAdoDBLib
Me.ConnSQLSrv = New ConnSQLSrv(Me.DBSrv, Me.MirrDBSrv, Me.CurrDB, Me.DBUser, Me.DBPwd, Me.ProviderSQLSrv)
PigSQLSrvLib or PigSQLSrvCoreLib
Me.ConnSQLSrv = New ConnSQLSrv(Me.DBSrv, Me.MirrDBSrv, Me.CurrDB, Me.DBUser, Me.DBPwd)
Execute this method to automatically connect to the online database after the mirror database fails over.
Me.ConnSQLSrv.OpenOrKeepActive
For more information, see the relevant links.
https://www.nuget.org/packages/ObjAdoDBLib/
https://www.nuget.org/packages/PigSQLSrvLib/
https://www.nuget.org/packages/PigSQLSrvCoreLib/
I am using the Sql Server powershell snapins (i.e. "SqlServerProviderSnapin100", "SqlServerCmdletSnapin100"). I execute scripts using powershell, but when I try to execute them again, I get a "No process is on the other end of the pipe" shared memory error. I need to close Powershell, and restart it before it will work again.
It appears that powershell is keeping a connection open, which is preventing the reexecution of the scripts.
Does anyone know how to solve this?
Thanks.
I found the answer.
The problem: The ADO connection pool is holding the connection once it is opened. Sql Server closes the connections, but the pool does not know of this, consequently, ADO assumes the connection is still valid, but it is not.
The solution: Execute [System.Data.SqlClient.SqlConnection]::ClearAllPools() first. This invalidates all connections that ADO is currently holding in the pool, and prevents the exception.
In a asp.net/Sqlserver project, we create connections using ado.net (sql authentication) and we see a behaviour where there are a lot of active connections in "sleeping","Awaiting command" status
The code does the following - Get a connection from common function, update db, Commit transaction, close & dispose transaction, close connection.
1) In sqlserver 2008 when our program runs for sometime (it updates the db every few secs), the number of active connections increases dramatically and sqlserver starts refusing new connections (as the default connections is 100)
2) In sqlserver 2005, we see that the connections are getting reused and work fine. Our max connections does not go above 15-20.
We found an issue from MSFT on 2008 and conveyed to the client.
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=383517 - Talks about 2008 not releasing closed connections immediately.
In the client place, we see the same issue in sql2005 too.
My question, is when the .net program calls close() on a connection, how long does sqlserver keeps it active ?
Thanks a lot for any hints
Regards
Anand
Connections are going to the pool. If they are not reused from there, and the number of connections increases, you certainly did not clean them up properly. Make use of using blocks for any disposable type (also transactions, commands and whatever).
To clear the connection pool you can call this static method:
SqlConnection.ClearAllPools();
This should remove all connections and are not used in the pool. The others are still in use.