When I try to create or alter stored procedures, it automatically disconnects dbserver.
It only does so for stored procedure create,alter.
This is the error I get:
A transport-level error has occurred when receiving results from the
server. (provider: TCP Provider, error: 0 - The semaphore timeout
period has expired.)
How can I solve this issue?
I am not sure if it's the problem but check the query execution option from Tools -> Options menu and go to Query Execution - > Sql Server -> Advanced section. As shown below Disconnect after the query executes option should be unchecked.
Related
My linked server was fine until now and i was selecting data using some join statement for filtering the but suddenly its returning following error. i cannot execute any query against my linked server.
Linked server is still available as i tried a TEST CONNECTION from server object and it was successful
Msg 65535, Level 16,State 1, Line 0
Sql Server Interface:Error Loading Server/Instance Specified
(xfffffff)
oledb provider sqlnc111 for linked server "MSNAC/MSDB5" returned an
error " A login time out expired
A network-related or instance-specific error has occurred while
establishing a connection to SQL Server. Server is not found or not
accessible. Check if instance name is correct and if SQL Server is
configured to allow remote connections. For more information see SQL
Server Books Online.
How to solve this issue ?
If nobody has made any configuration changes, your queries may be timing out because of a big data change. Try to, at least temporarily, set the following option:
USE Yourdatabase;
GO
EXEC sp_configure 'remote query timeout', 0;
GO
RECONFIGURE;
GO
If it goes fine with these settings, your queries were simply timing out because of the set limit. Experiment a bit with your queries, see what is an appropriate limit to put in this properties (leaving it to infinity isn't a good idea) and reconfigure once again.
NOTE: the number is in seconds.
To read up more on this issue, check the documentation for remote query timeout.
Hi During Synchronizing My Database I got These Expectations ....
Failed To Excute the command 'SelectRowCommand' For table 'abc' the
transation was rolled backed .Ensure the Command Syntax is Correct...
A network -related or instance specific error occurred while
establishing a connection to SQL Server . Server was not found or was
not accessible .Verfiy .....
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.
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...
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.