Enjoy Every Sandwich

Thoughts on SQL, XML, .NET and sometimes beer.

<November 2008>
SuMoTuWeThFrSa
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456


Navigation

Tools

List O'Links

Kent's Other Stuff

Subscriptions

News

Please read these
Notices and Disclamiers

Post Categories

Article Categories



Thursday, March 23, 2006 - Posts

Burning, Pillaging and Armed Robbery at 7AM? Its a nice way to start a day.

My morning ritual is pretty simple: wake up, find coffee and go downstairs to logon and check email. For a little background sound, I'll turn on Music Choice on the TV. Today, no. Our TV is set up to automatically start on FoodTV, which is nothing but Infommericals at this time. Somehow rather than hitting channel 930 on the key (for Jazz), it entered 0-5-5. Turner Classic Movies. Ok, so I like TCM. And that's certainly true this morning...

Shichinin no Samurai. AKA, The Seven Samurai. What a nice way to start the day. One of the best lines EVER in a movie...

Danger always strikes when everything seems fine.

Great, now I'm going to be paranoid all day.

posted Thursday, March 23, 2006 8:04 AM by ktegels

How to make a Trigger when all you have are Events and Notifications

As usual, some of the best questions come from the newsgroups. And yet again, there was one that piqued by attention. The question essentially boiled down to “can you put a trigger on a login?” That is, the questioner wanted to execute some arbitrary T-SQL code whenever a user logged into a given instance of SQL Server. I’m not sure how you’d go about doing this in SQL Server 2000, but in 2005, two features make this possible – if you don’t mind building a bit of your own plumbing. These features are EVENT NOTIFICATIONS and the Service Broker.

Event Notifications are essentially fixtures that your create – using T-SQL – that allows SQL Server to dispatch messages about system events like logins, data definition language statements, and some trace events to Service Broker Services and Queues. The Service Broker Service acts as an address for the messages, while the Queue holds the messages until some a process like a Stored Procedure process them. Some number of instances of that Stored Procedure will be spawned by a process called Activation when a message arrives in a Queue. So these two features work together to deliver information about system events to a stored procedure that gets executed in response to that event, much like how a trigger gets fired in response to events.

What started out as fairly short post turned into a fairly long item, so I've contued this over here, while the annotated source code (with bonus features) is over here.

posted Thursday, March 23, 2006 12:10 AM by ktegels




Powered by Dot Net Junkies, by Telligent Systems