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.
Related
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)
I use RODBC to send queries to an SQL-Server. Sometimes they take too much time to run, so I need to cancel them.
Clicking the red "stop" button in RStudio yields this error message:
R is not responding to your request to interrupt processing so to stop
the current operation you may need to terminate R entirely.
Terminating R will cause your R session to immediately abort. Active
computations will be interrupted and unsaved source file changes and
workspace objects will be discarded.
Do you want to terminate R now?
And if I click yes my session is indeed terminated. (note: using Rgui instead of RStudio doesn't make things better)
However:
when I use another software (named "Query ExPlus") to connect to this same SQL-Server, I have a similar stop button, and clicking it instantly interrupts the query, without any crash.
when I connect to a PostgreSQL database using the RPostgres package I can also interrupt the query at any time.
These two points lead me to think that there should be a way to solve my problem. What can I do?
So far my workaround is:
library(RODBC)
library(R.utils)
withTimeout(mydf <- sqlQuery(myconnection, myquery), timeout=120)
Note: I don't have permission to kill queries from the database side.
I've just stumbled upon the odbc package. It allows to interrupt a query at any time.
Basic usage goes like this:
library(DBI)
myconnection <- dbConnect(odbc::odbc(),
driver = "SQL Server",
server = "my_server_IP_address",
database = "my_DB_name",
uid = "my_user_id",
pwd = "my_password")
dbGetQuery(myconnection, myquery)
I don't have a deep understanding of what happens behind the scenes, but for what I've seen so far in my personal use this package has other advantages over RODBC:
really faster
get the column types from the DB instead of guessing them (see here)
no stringsAsFactors and as.is arguments necessary
Most SQL Server users use SQL Server Management Studio (which is free and can be downloaded from Microsoft) to connect to SQL Server or execute commands from the command line via a tool called SQLCMD.
If you can determine the session id that the SQL Command is being run in you can kill the session which would stop any executing command(s). SQL Server will still need time (could be a 'long' time) to rollback any changes made during the execution of the command.
Terminating a session (depending on the software) can take a while to communicate to SQL Server that the session has been terminated. When I connected to DB2 from SQL Server using linked servers DB2 would buffer the terminate command and it would frequently take up to an hour for DB2 to realize the session had been terminated.
To determine what the session you are running in you can try:
select ##spid;
once you have the spid (lets say 86)
you can then issue (depending on if you have permission to do so)
kill 86;
but as Microsoft notes:
Terminates a user process that is based on the session ID or unit of work (UOW). If the specified session ID or UOW has a lot of work to undo, the KILL statement may take some time to complete, particularly when it involves rolling back a long transaction.
Try to close your "tab query" on SQL Server Management Studio
Then it will appear pop-up,
This Query is currently executing. Do you want to cancel this query ?
Cancel anyway, choose "yes".
try to set your connection prior to query:
sql = odbcConnect('Database name')
Then use same line to run your query:
mydf <- sqlQuery(sql, " myquery ")
Note: The running time is dependant on both database and R server but setting up the connection this way should resolve termination problem.
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 a Symfony command line task that has a habit of dropping the mysql connection.
Its a data import task. Which fetches data from multiple connections. Its not one big query but a few smaller ones.
It seems to drop the connection the first time it is ran. About half way through the script. However the second time its ran (from the beginning) it always completes the task.
Its not timing out on the query as the error response I get is that the connection has been dropped and it runs ok on its own. So im thinking that its some kind of timeout issue that is avoided when its ran the second time due to query caching speeding up the script.
So my question is how do I refresh the database connection?
[Doctrine\DBAL\DBALException]
SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server during query
A different approach is to check if Doctrine is still connected to the MySQL server through the ping() method in the connection. If the connection is lost, close the active connection since it is not really closed yet and start a new one.
if(FALSE == $em->getConnection()->ping()){
$em->getConnection()->close();
$em->getConnection()->connect();
}
I guess you mean to connect to the database if the connection is lost for some reason. Given an EntityManager, you can do it the following way:
$success = $_em->getConnection()->connect();
With getConnection, you are retrieving the connection object doctrine uses (Doctrine\DBAL\Connection), which exposes the connect method.
You can call connect anytime, as it checks wether a connection is already established. If this is the case, it returns false.
There is also a isConnected method to check wether a connection is established. You could use that to see where exactly the connection is dropping to get a clearer picture of what is happening.
I am trying to connect to a biztalk instance over the network, and not being all that successful. The SQL server with the biztalk databases on it has named pipes disabled. When I try to connect to the server that has biztalk installed, it gives a named pipes error. When I try to connect to the database server, it just times out and gives an error that covers virtually every scenario under the sun (basically it can't connect and it doesn't know why)
If I try to connect with SQL Server Management Studio it works. If I try to make a dsn, it works. If I try to go through biztalk, it dies. If I try to go through biztalk with the tcp: prefix, it dies. If I force named pipes on the other two, it dies.
Is there any way from the Connect to existing group dialog to force using TCP/IP as the transport?
To force tcp , try "tcp:servername" (or "tcp:servername\instancename,port")
This can be done without setting an alias or default protocol with SQL tools
There are alternatives to why you may get the error though:
The named pipes error can be misleading, It usually just means "can't find server"
firewalls etc are blocking access to either the SQL instance
... or SQL listener port 1434 thats enumerates instance/ports
do you get any error messages in system or application log?
you may need to check some of the shapes - ports etc as there may be
http://www.biztalkserverguide.com/2008/02/04/biztalk-server-throwing-named-pipes-error-40-could-not-open-a-connection-to-sql-server/
declared a variable called btsConnString (string), this varable was not set to the connection string, it was blank ( by mistake), things were working as expected without issue. On the Stage As the btsConnString wasn’t assigned a connection string, it was throwing the error
Also look at MSDTC issues for connection DTC Test is here http://support.microsoft.com/kb/293799 and if you can install on both servers use DTCPing
also look at theseThe majority of Microsoft SQL Server issues that affect Microsoft BizTalk Server 2006 fall into one of the following categories:
I believe I had something similar fairly recently - BizTalk would try to connect to the SQL box using named pipes for some obscure reason, which would time out.
We've using the registry (HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\SuperSocketNetLib) to force it to try TCP first (and last, and we haven't specified any other protocol) and it seemed to do the trick.
See details here
I know this is an extremely old thread but for reference with the exact same problem. I ended up creating an alias to the instance in SQL Server Configuration Manager. Your alias would look like this: Alias = Aliasname Value = Server\Instance. Then put Aliasname as your datasource in your connection string. Seems to me BizTalk doesn't understand the backslash (\) in the connection string. It must have the a single word.