January 3, 2012 at 9:04 am
I've set up some alerts, based on this article[/url]
Now I would like the Job that is triggered by the alert to send some information to a c# application (this application, can be running in the same machine of the SQL instance, and then the C# application sends the information to other machine).
My application can accept TCP connections so I was thinking about using that, but any other form for the SQL server to communicate with my application is also welcome.
Any suggestions in how I can do this?
Background info: I'm doing this to monitor when the Principal server is running exposed, and when the Mirror server is synchronized. So that if the witness goes down, and then the principal, based on the records of these alerts I can tell if its safe to promote the Mirror to Principal.
Note, that in this case scenario I cant read the mirror database without break the mirroring configuration, so using a table inside the Mirrored database is not a solution.
January 3, 2012 at 10:42 am
In essence, what you want is for the C# application (or thread) to be waiting (sleeping) for an event that comes in the form of a message sent from SQL server. But while it is waiting we don't want it to be spinning, polling or otherwise consuming resources.
One of the easiest and effective ways to do this is by using Service Broker. Create a message queue and provide a stored procedure for the application to call which reads on the message queue. When a message arrives, sent by a process in SQL server, it will wake up and return the message to the application to be processed.
Since the interface is a SQL server connection it can use any protocol (named pipes, shared memory or TCP/IP) that SQL server supports.
The probability of survival is inversely proportional to the angle of arrival.
Viewing 2 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply