Call rabbitmq using SQL Server CLR - sql-server

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;

Related

Linked Server Connectivity Issues?

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.

Resource limit error in linked server

I have a problem with running a query in a linked server, I use sql sp’s for ETL process in my BI project
(For some reason I cannot use ssis).one of my queries witch has to read recently changed records and insert them in my warehouse take too long to execute and always fail with this error:
OLE DB provider 'SQLOLEDB' reported an error for linked server ‘XXX’. Execution terminated by the provider because a resource limit was reached..
But other queries run successfully. I also run following scrip in my linked server (warehouse) to increase timeout threshold.
sp_configure 'remote login timeout', 30
go
reconfigure with override
go
sp_configure 'remote query timeout', 0
go
reconfigure with override
go
Hint: I’ve used change tracking option in source tables to track updates and inserts..
I would be really thankful if someone could help me out of this.

sp_reset_connection error in SQL Azure Linked Server RPC

I have a problem calling a remote Stored Procedure (RPC) on my SQL Azure, passing through a Linked Server (build on a Sql Server 2008 R2 instance: 10.50.2550.0 - x64 - Enterprise Edition).
This issue is not difficult to reproduce, and it's not really related with "calling" the Stored Procedure, but with its internal execution (I think)...
Take a look to my simple code:
CREATE PROCEDURE [dbo].[myStoredProcedure]
#AccountId INT = NULL
AS
BEGIN
DELETE FROM [dbo].[myTable];
INSERT INTO [dbo].[myTable] (Col1, Col2)
SELECT DISTINCT
Value1
, Value2
FROM [dbo].[myTableSource];
END
GO
GRANT EXECUTE ON [dbo].[myStoredProcedure] TO [myDbRole]
GO
When I launch this through my Linked Server, using this code (on a connection from my local instance, where the Linked Server has been created)...
EXEC('[AZURE_LINKEDSERVER].[myDatabase].[dbo].[myStoredProcedure] #AccountId = NULL')
...I get this error (that seems a warning!):
Message 2812, level 16, state 62, row 1
Could not find stored procedure 'sp_reset_connection'.
And obviously I checked everywhere and I'm not calling that Stored Procedure...that I think it's internally used by Sql Server.
I also tried this code, same result:
EXEC sp_sqlexec '[AZURE_LINKEDSERVER].[myDatabase].[dbo].[myStoredProcedure] NULL'
The Linked Server has "remote RPC enabled" (rpc and rpc out options are both set to True) and works great with other Stored Procedure and every other OPENQUERY code I used until now: also permissions work fine.
The strange thing is that the first part of the SP is correctly executed (I see query result count in the Messages window of SSMS), but the second is not called at all.
Can you please tell what's the SP sp_reset_connection is related to?
Do you know a workaround to call my SP without errors?
I tried everything...
SQL Azure in use has version 11.0.9231
sp_reset_connection is not an actual stored procedure it is a flag in the TDS stream that says "Reset the connection" so you can use connection pooling. It should exist on all SQL Servers implicitly but cannot be called by your code.
what type of linked server have you setup? follow this to create a linked server to azure:
http://blogs.msdn.com/b/sqlcat/archive/2011/03/08/linked-servers-to-sql-azure.aspx

Error: No process is on the other end of the pipe

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.

SQL Strange Timeout Issue

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...

Resources