I want SQL server to send message to external application, Is that possible with SQL server?
I did google a lot but don't find useful material/Link. Any appropriate answer would be appreciated.
You can use RAISERROR for what you want.
RAISERROR('My Error Message',0,1)
This will work if the external application runs a query (like a stored procedure) and the query has this line. So for instance if you know the application runs sp_sample, then in sp_sample :
ALTER PROCEDURE sp_sample
AS
BEGIN
--Procedure normal code
RAISERROR('My Error Message',0,1)
END
This will execute the code (an INSERT for instance) and then send the message back to the application.
In theory is possible, because SQL Server can host CLR procedures and these procedures, if granted EXTERNAL_ACCESS permisssion, can do pretty much anything they please, including calling web services or JMS apps.
But is not recommend, for many reasons (performance, security, maintenability, deployment and configuration, troubleshooting and many more) . Use an external application to do your communication and let SQL Server just manage data.
Related
I am using SQL Server Broker on SQL Server 2008 for Scaleout with SignalR v2.1.2. It was recently discovered that we are producing 50k+ errors per day in our DB logs. After some research, there are 3 orphaned Service Broker queues from December. Error example:
2016-02-27 23:58:01.79 spid30s The activated proc '[dbo].[SqlQueryNotificationStoredProcedure-2ffbddba-6ddc-4ad0-88b4-45a405e975e0]' running on queue 'MY_SIGNALR_DB.dbo.SqlQueryNotificationService-2ffbddba-6ddc-4ad0-88b4-45a405e975e0' output the following: 'Could not find stored procedure 'dbo.SqlQueryNotificationStoredProcedure-2ffbddba-6ddc-4ad0-88b4-45a405e975e0'.'
These queues were created in December and were NOT dropped for some reason. The corresponding SPs were apparently dropped as expected. The DB will produce an error every 5 seconds for this (equates to 50k per day with 3 queues). Each queue DOES contain a message.
Questions:
What can cause this?
Are there additional SignalR settings that can be implemented to ensure these are cleaned up?
Is this a bug in SQL Server Service Broker?
Is there a document which describes SignalR's expected behavior with regards to Queues and their expiration?
Thank you for your time.
These are leftover from SqlDependency. The implementation of the SqlDependency.Start() is to create a just-in-time service, queue and activated procedure (see the reference source). This has some issues, and even a simple Visual Studio debugging session can leave stranded queues/activated procedures.
You can clean up these left-over service/queue/procedures as they happen, or you can choose to use the lower level SqlNotificationRequest class and handle the service/queue deployment on your own. Pick your poison.
I would like to know how to use a web service from a SQL Server stored procedure. I have a table in which the columns specify the city and state of the user. I want to pass this address as a parameter to Google Geocoding API web service and get the latitude and longitude.
I have successfully made use of this geocoding api in c#. But now, I want to use it in a stored procedure.
Can any one please suggest how to get this done? Or please provide me any links?
Any help will be appreciated!!
Thanks.
For something like this, you don't need a full web service implementation. You can use SQLCLR (SQL Server's .NET Integration) to submit the request to the URL, get the response back in XML (unless you can find a JSON library that will work without being set to UNSAFE), and then parse that response.
Look at the following MSDN pages:
HttpWebRequest
HttpWebResponse
XmlDocument
To escape the address:
If you are using SQL Server 2005, 2008, or 2008 R2, then use Uri.EscapeDataString as it was available prior to .NET Framework v4.5
If you are using SQL Server 2012, 2014, or newer, then you can use either Uri.EscapeDataString or, if the server has been updated to at least .NET Framework v4.5, then you can alternatively use WebUtility.UrlEncode
According to the Google Geocoding API documentation, the API URI should be formatted similarly to the following:
https://maps.googleapis.com/maps/api/geocode/xml?address={EscapedAddress}&key={API_KEY}
Just submit that with those 2 variables substituted with their proper values via HttpWebRequest, then call HttpWebRequest.GetResponse, then call HttpWebResponse.GetResponseStream. And do not forget to call the Close and Dispose methods of HttpWebResponse (or instantiate it in a using block)!!
Additional notes:
If not already done, you will have to enable (one time) "CLR Integration" at the server level: Enabling CLR Integration
Do not take the easy road and set the database to TRUSTWORTHY ON. Just sign the assembly with a password, then create an asymmetric key in the master database by pointing to your signed DLL, then create a login from that asymmetric key, and finally grant that login the UNSAFE ASSEMBLY permission. Then you can set the assembly WITH PERMISSION_SET = EXTERNAL_ACCESS.
Do not use the SP_OA* procedures as advocated by user3469363. Those OLE Automation procedures have been deprecated since SQL Server 2005 and will (hopefully) be removed someday (hopefully soon). They are also less efficient and less secure than SQLCLR.
Even more notes can be found in my answer to a similar question on DBA.StackExchange: Bringing web service data into SQL server
Omar Frometa has an example on how to do this. go this link
http://www.codeproject.com/Articles/428200/How-to-invoke-a-Web-Service-from-a-Stored-Procedur
In summary, use these extended stored procedures: SP_OACreate and SP_OAMethod to access objects such as MSXML2.ServerXMLHttp.
I've a scenario where I've to send a mail after checking a condition after every insert in a table.
Is trigger the right way to do it?
My second question would be as to what approach to take
Should I directly send a mail from the DB. (Note: My DBserver and Mail server are in different networks, might've to create firewall rule exception)
Should I have a CLR-sproc. From the DB, I call the CLR-sproc and CLR-sproc calls a service and from there sends the mail.
Is there a better approach?
Both SQL Server DBMail and a CLR proc will use SMTP to send the email. So, why add complexity?
In addition, sending an email via DBMail or CLR will require processing on INSERT. Note that DBMail uses a queue so will impact less than running a CLR procedure.
A trigger is a good way to do it. However, consider using a stored procedure to do the ISNERT with the email sent outside of the transaction (you'll have an implicit one because of the INSERT). Sending in a trigger means it is part of the implicit transaction for the INSERT.
From a security perspective, SQLMachine still needs access to SMTPMachine, whether using DBMail or a service call by a CLR Proc.
1) Yes, a trigger would be the right way of performing an action after every insert
2) SQL server has a feature called Database Mail which looks like it will do what you want (although I've never used it myself)
We have a .NET3.5 Windows Forms application that calls an ASP.NET SOAP web service on the same server. This web service then saves the data into a SQL Server Express 2005 database, again on the same server.
The application has been deployed internally, as well as to a number of our customers and has worked as expected for over 18 months. However this week, at our main customer's site, the application has started generating an error message on four out of the 10 servers it is deployed on. All of the web service methods use the same connection string, but only one web method is affected.
The connection string has this format:
Data Source=MYSERVER\SQLEXPRESS;Initial Catalog=MyDatabase;
Persist Security Info=True;User ID=MyUser;Password=MyPassword
When the application calls one particular web service method, it is producing an error:
Cannot find the user 'MyDatabase', because it does not exist or you
do not have permission.
There have been no changes to the application to cause this, however the customers' IT people may have made changes to these servers. MyUser has been granted permissions on the stored procedures and is able to connect to all of the other web service interfaces.
The main thing that is confusing me is that the error messages says that the user that does not exist is MyDatabase which is the Initial Catalog name in the connection string.
I have been onsite with the customer and verified that the application is still set up correctly and that all of the other web service interfaces are correctly connecting to the database.
Any suggestions of either possible causes or other things I can check would be gratefully received.
I would strongly advise against removing the dbo. That is the schema name. Simply removing it will imply to the DB to use the default schema, which is probably dbo anyways. So it would accomplish nothing. But by not using the schema name when calling the procedure you can run into naming conflicts. For example, if you have a procedure with the same name in two different schemas in the DB, and you try to call it without a schema name, the DB will not know which one to call, resulting in an exception.
We have a classic ASP application that simply works and we have been loathe to modify the code lest we invoke the wrath of some long-dead Greek gods.
We recently had the requirement to add a feature to an application. The feature implementation is really just a database operation requires minimal change to the UI.
I changed the UI and made the minor modification to submit a new data value to the sproc call (sproc1).
In sproc1 that is called directly from ASP, we added a new call to another sproc that happens to be located on another server, sproc2.
Somehow, this does not work via our ASP app, but works in SQL Management Studio.
Here's the technical details:
SQL 2005 on both database servers.
Sql Login is authenticating from the ASP application to SQL 2005 Server 1.
Linked server from Server 1 to Server 2 is working.
When executing sproc1 from SQL Management Studio - works fine. Even when credentialed as the same user our code uses (the application sql login).
sproc2 works when called independently of sproc1 from SQL Management Studio.
VBScript (ASP) captures an error which is emitted in the XML back to the client. Error number is 0, error description is blank. Both from the ADODB.Connection object and from whatever Err.Number/Err.Description yields in VBScript from the ASP side.
So without any errors, nor any reproducibility (i.e. through SQL Mgmt Studio) - does anyone know the issue?
Our current plan is to break down and dig into the code on the ASP side and make a completely separate call to Server 2.sproc2 directly from ASP rather than trying to piggy-back through sproc1.
Have you got set nocount on set in both stored procedures? I had a similar issue once and whilst I can't remember exactly how I solved it at the moment, I know that had something to do with it!
You could be suffering from the double-hop problem
The double-hop issue is when the ASP/X page tries to use resources that are located on a server that is different from the IIS server.
Windows NT Challenge/Response does not support double-hop impersonations (in that once passed to the IIS server, the same credentials cannot be passed to a back-end server for authentication).
You should verify the attempted second connection using SQL Profiler.
Note that with your manual testing you are not authenticating via IIS. It's only when you initiate the sql via the ASP/X page that this problem manifests.
More resources:
http://support.microsoft.com/kb/910449
http://support.microsoft.com/kb/891031
http://support.microsoft.com/kb/810572
I had a similar problem and I solved it by setting nocount on and removing print commands.
My first reaction is that this might not be an issue of calling cross-server, but one of calling a second proc from a first, and that this might be what's acting differently in the two different environments.
My first question is this: what happens if you remove the cross-server aspect from the equation? If you could set up a test system where your first proc calls your second proc, but the second proc is on the same server and/or in the same database, do you still get the same problem?
Along these same lines: In my experience, when the application and SSMS have gotten different results like that, it has often been an issue of the stored procedures' settings. It could be, as Luke says, NOCOUNT. I've had this sort of thing happen from extraneous PRINT statements in the code, although I seem to remember the PRINTed value becoming part of the error description (very counterintuitively).
If anything is returned in the Messages window when you run this in SSMS, find out where it is coming from and make it stop. I would have to look up the technical terms, but my recollection is that different querying environments have different sensitivities to "errors", and that a default connection via SSSM will not throw an error at certain times when an ADO connection from a scripting language will.
One final thought: in case it is an environment thing, try different settings on your ASP page's connection string. E.g., if you have an OLEDB connection, try ODBC. Try the native and non-native SQL Server drivers. Check out what connection string options your provider supports, and try any of them that seem like they might be worth trying.
Example code might help :) Are you trying to return two tables from the stored procedure; I don't think ADO 2.6 can handle multiple tables being returned.
I did consider that (double-hop), but what is the difference between a sproc-in-a-sproc call like I am referring to vs. a typical cross-server join via INNER JOIN? Both would be executed on Server1, using the Linked Server credentials, and authenticating to Server 2.
Can anyone confirm that calling a sproc cross-server is different than doing a join on data tables? And why?
If the Linked Server config is a sql account - is that considered a double-hop (since what you refer to is NTLM double-hops?)
In terms of whether multiple resultsets are coming back - no. Both Server1.Sproc1 and Server2.Sproc2 would be "ExecuteNonQuery()" in the .net world and return nothing (no resultsets and no return values).
Try to check the permissions to the database for the user specified in the connection string.
Use the same user name in the connection string to log in to the database while using sql mgmt studio.
create some temporary table to write the intermediate values and exceptions since it can be a effective way of debugging your application.
Can I just check: You made the addition of sproc2? Prior to that it was working fine for ages.
Could you not change where you call sproc2 from? Rather than calling it from inside sproc1, can you call it from the ASP? That way you control the authentication to SQL in the code, and don't have to rely on setting up any trusts or shared remote authentication on the servers.
How is your linked server set up? You generally have some options as to how it authenticates to the remote server, which include logging in as the currently logged in user or specifying a SQL login to always use. Have you tried setting it to always use a specific account? That should eliminate any possible permissions issues in calling the remote procedure...