Ok, so I am trying to create a procedure that call an extended procedure. I am getting the following error:
Msg 121, Level 20, State 0, Line 0
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)
Even with the simplest test I get that error:
CREATE PROCEDURE Test
AS
BEGIN
EXEC xp_cmdshell 'dir *.exe'
END
However if I just run xp_cmdshell 'dir *.exe' by itself it works.
This is running on a clustered SQL 2005 server. Any help is appreciated.
Are you getting the error when you CREATE the procedure or when you EXECUTE it?
If you get it when you execute it, then there could be some issue with permissions. Since in later versions of sql server calling xp_cmdshell is tightly locked down and by default not enabled in the surface area configuration, I could see a potential for this.
How are you calling the SP? If you're using dynamic SQL, then know that it executes with the privileges of the caller, not the SP creator.
Do you need to prefix the SP with master as in master.dbo.xp_cmdshell?
Have you tried EXECUTE AS either in the SP creation or in the SP execution?
Also, in my experience, transport-level errors are sometimes not due to a problem with the server but a problem with the client caching its connection object past the time when the server has dropped it (thus invalidating the connection object). Given that you're presumably running this within just a short time of initially connecting, it doesn't sound like that is the exact problem, but could you be having some kind of proxy/firewall/net filter issue that is dropping packets because of detecting certain keywords in the packets? I know this is a long shot but I had to ask...
Related
I have implemented this article to call rabbitmq inside SQL Server:
[https://nielsberglund.com/2017/02/11/rabbitmq---sql-server/][1]
But when I try to send a message using the CLR I get this error:
Msg 50000, Level 16, State 1, Procedure pr_SomeProcessingStuff, Line 43
Error: A .NET Framework error occurred during execution of user-defined routine or aggregate "pr_clr_PostRabbitMsg":
System.ApplicationException: Channel pool blocked when trying to post message to Exchange: amq.topic.
System.ApplicationException:
at RabbitMQSqlClr.RabbitPublisher.Post(String exchange, Byte[] msg, String topic)
at RabbitMQSqlClr.RabbitMQSqlServer.pr_clr_PostRabbitMsg(Int32 endPointId, String msgToPost)
at line: 0 at line: 13
This is my rabbit config
Firstly, big thanks to #NielsBerglund for giving us RabbitMQ-SqlServer.
I have just resolved the same error after a quite a few hours of head banging.
I was able to use the console app in the VS solution Neils provided to send a message between the two different servers (database server and application server), therefore proving that firewalls etc were not blocking the message.
However, executing the SQL CLR stored procedure within SQL Management Studio always returned the channel pool blocked error.
After much tinkering, I noticed that changing the exchange name in tb_RabbitEndpoint (using pr_UpsertRabbitEndpoint) was still returning the exact same error message, referencing the previous exchange name.
I was able to resolve this by re-configuring SQL CLR:
EXEC sp_configure 'CLR Enabled', 0
GO
RECONFIGURE
GO
EXEC sp_configure 'CLR Enabled', 1
GO
RECONFIGURE
GO
EXEC rmq.pr_clr_InitialiseRabbitMq;
I have a SQL Server Agent Job with one step. The step executes a stored procedure on the local server, and nothing more. When the job executes (either manually or scheduled), I receive the following error. The job fails after about 23 seconds.
Msg 121, Level 20, State 0, Line 0 A transport-level error has
occurred when receiving results from the server. (provider: TCP
Provider, error: 0 - The semaphore timeout period has expired.)
However, I have no problem executing the stored procedure manually. I receive the proper results in less than a second.
The 'semaphore' error tends to be a hardware or network issue. But since the job is executing on the local server, I am unclear how hardware or network latency could be an issue.
UPDATE (things I've tried)
After each of these attempts, I put everything back to its original state. Each of these attempts has the same results (works when I RDP to the server, fails everywhere else).
The underlying stored procedure calls out to a linked-server. I removed these references.
Assuming the problem is some kind of call out to the AD domain-controller, I used a SQL Login instead of a Windows User.
I modified the job to run as me (since I can do everything).
Another note: When executing, the job fails to start. So, it's not even getting to the stored procedure.
I would approach this problem by following below steps...
1.Ensure Query is finetuned
2.Ensure stats and indexes are upto date
Semaphore time outs mostly relate to insufficient memory in the system..So updating stats will help sql server in getting memory estimates right..and this should solve most of timeouts
But since the job is executing on the local server
I assume you meant ,you are running job in same box as of server..not remotely..even in this cases ,we faced time outs(general),but we ruled out hardware and network issues through below steps
TCP Offloading/Chimney & RSS…What is it and should I disable it?
changed Remote Login,Remote query time outs(these may not be applicable to your error message)
I'm using SQL Server 2012 (localhost only) and SQL Server management Studio (SSMS) to view a table picture that contains binary values (pictures), 928 rows in size which is not large. And only that table has the problem.
It shows the below error, both locally and from another PC, even after restarting SQL Server:
Msg 233, Level 20, State 0, Line 0
A transport-level error has occurred when receiving results from the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.)
I would start by checking the consistency of your data. Run a DBCC CheckDB against your DB. You may have corruption in the table. You can also try selecting against msdb.dbo.suspect_pages
To comment on the accepted answer, running DBCC CheckDB highlighted various errors in the table I couldn't select from. Then DBCC CheckTable(TableName) confirmed it. To fix:
DBCC CheckTable(TableName,repair_allow_data_loss)
However, you'll need the database in Single User mode: right click the database in Object Explorer, Properties, Options, (scroll to bottom), State, Restrict Access -> SINGLE_USER will do this.
It is clearly stating transport level error.... SO in protocols for the same instance check whether 'Named pipes' is enabled or disabled... if Disabled , enable it and restart the services, issue will be resolved. If enabled , restart the services as it does not take into effect until and unless services are restarted
Make sure your firewall is not blocking the Distributed Transaction Coordinator(in and Out)
I've seen this error today while I was running my SP.
I was able to figure out by analyzing what has changed.
I added an insert statement and the reason for above hard error was because I accidentally switch two fields: VARCHAR and DATETIME, like this:
INSERT INTO Table
(Id, UserName, UpdatedOn)
VALUES (1, GETDATE(), 'user')
-- values should have been in 1, 3, 2 order
I'd imagine SQL server should have catch this in a nicer manner, but end up with
A transport-level error has occurred when receiving results from the
server. (provider: Shared Memory Provider, error: 0 - No process is on
the other end of the pipe.)
Anyway, posting as someone may find it helpful.
I am running Access 2010 FE and SQL Server 2005 BE.
I can execute pass through queries to my SQL Server succesfully by using DSNless connections.
During my testing phase sometimes I need to restore my database to get back to my original records so I can rerun my pass through queries. What I have found is when I run a pass through query, it creates an active connection on my SQL Server. I see the connection via the SQL Server Management Console under the MANAGEMENT | SQL Server Logs | Activity Monitor, select view processes. There I can see which process ID is being used and who is using it when I run my pass through query.
Now the only way for me to restore my database is to KILL the PROCESS e.g. Active connection
Now when I have my restored database in place and re-run the pass through query, I receive a ODBC -- Call Failed message box. I have attempted to run a procedure to refresh my querydefs but to no avail, I will still get the ODBC-- Call Failed message box when I click on those objects.
Now there are two options on how to fix this problem, which in either case I find not USER Friendly.
Restart my Access Application
Wait approx 5-10 minutes to rerun the Pass Through Query
I created a function to trap my ODBC Errors and this is what appears:
ODBC Error Number: 0
Error Description: [Microsoft][ODBC SQL Server Driver]Communication link failure
ODBC Error Number: 3146
Error Description: ODBC--call failed.
So if for some reason, I need to restart my SQL server or kill a process (Active Connection) on my SQL server while the Access Application is currently connected via ODBC, the objects created via ODBC will not perform properly till I execute the 2 workaround solutions as stated above.
Can anyone shed some advice on a solution? I appreciate any insight.
I asked a similar question some time ago, and never got a satisfactory answer. My original question is here: Force SET IDENTITY_INSERT to take effect faster from MS Access
There is a registry setting documented here for ACE that controls the timeout behavior:
ConnectionTimeout: The number of seconds a cached connection can remain idle before timing out. The default is 600 (values are of type REG_DWORD).
So as a third workaround (in addition to the two you already listed) you can change that registry setting to a shorter timeout (like 10 seconds). This is the approach I took in my answer. One caveat is that shortening the timeout may cause performance or other issues. Your mileage may vary.
See my full answer to the original question for more info.
I get the following error when I call a stored proc within an execute sql task in SSIS.
"Description: Executing the query "Exec up_CallXXX" failed with the following error: "Incorrect syntax near '13'.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly."
This is how it is set up:
ResulSet : None
ConnectionType : OLE DB
SQLSourceType : Direct input
SQL Statement : Exec up_CallXXX
IsQueryStoredProcedure : False
BypassPrepare : True
The stored proc runs fine when I execute it through SSMS.
Does anyone have an idea what is going on.
Thanks!
This isn't really a complete answer, but the quickest route to troubleshooting this problem is likely to be to capture the command that SSIS is actually trying to execute using a SQL profiler trace, since I think SSIS uses sp_executesql to carry out "Execute SQL" tasks.
Once you have the text of the query SSIS is running, you may find that you can replicate the error if you execute it in SSMS.
I've had this kind of problem when the session settings for my SSMS session are different from the session settings used by SSIS/SSRS. Given the error message, it might be worth checking the SET QUOTED IDENTIFIER values in both sessions - but this is a guess.