I'm at ITForum in Barcelona, day 2. I've got the 17:00 talk and its on Troubleshooting Service Broker. It's warm and sunny outside, especially for November, and I'll need to think up something extrordinary to keep people inside and at the talk. How about having Service Broker make the sun shine inside programmatically..you can do anything with a database, right? Unfortunately, the .NET assembly System.Sunshine.dll is not on the "approved assembly" list for SQLCLR. Must not have done that reliability testing that SQLCLR folks require.

For everyone that was at my Key Management talk yesterday and said they couldn't live without the demo scripts I was using, the scripts will be, along with the Broker Troubleshooting and the XML for DBAs scripts, on the SQLskills website when the conference ends. Look under the "Past Events". By next week, this will be a "past event" and the sunshine a distant memory. Sigh.

I'm at ITForum in Barcelona this week. I'll be speaking on three topics that are:

1. Completely or almost completely new in SQL Server 2005
2. Take some DBAs a bit out of their comfort zone

If you've been avoiding these features until now, its time to take the plunge and let these features help you, rather than avoid them and do without the beneifts they provide. The topics are:

1. XML for DBAs - Showplan, DDL triggers and lots of things other things YOU use are XML.
2. Key Management - this is useful even if you don't do data encryption. Linked servers and SQL Agent use encryption keys.
3. Service Broker troubleshooting - Event Notifications and Database Mail (among others) use Service Broker.

See you there.

Last week at TechEd I was showing off Query Notifications. When I showed using the preprovisioned queue (overloads on SqlDependency.Start and SqlDependency constructor), a delegate asked about using the same queue with more than one subscriber. He repeated the question when I showed the low-level SqlNotificationRequest.

I did some tests over the weekend and the answer is no. You need a separate queue for each subscriber, otherwise the SqlDependency listener gets "confused". If you use the dynamically created queues like most people do (SqlDependency.Start with only a connection string), you get a new queue and service for each subscriber. So you won't notice this. I thought I'd have better luck with the SqlNotificationRequest because I'm reading the queue myself, but without going to the system tables (and perhaps introducing race conditions) its not possible there either.

Queue are cheap to create, so there is really no reason not to create a separate pre-provisioned queue and service for each notification subscriber. But, at least for the time being, its a requirement.

I've been doing my talk on try-catch in T-SQL for a while and whining about not being able to "rethrow" (via RAISERROR) a system error. Even went as far as writing a RegEx decoder so that I can copy the error into a user error message text and parse the text back on the client. Two weeks ago in a class, and again this week at TechEd, someone suggested the simple, relatively low-tech solution; "Just add 50000". RAISERROR to rethrow and subtract 50000 at the client. Unless you have already defined user errors in the range that can't be rethrown + 50000 (up to 13000), this should work fine. Thanks for the suggestion.

Sorry, I know that slogan has been used already. Thanks to everyone who showed up for the SMO/Powershell chalk talk at TechEd Barcelona today. Here, as promised, are the demos. Thanks especially to Jeffrey Snover, the "dad" of Powershell for showing up and showing me some neat shortcuts... as I typed. Many of the scripts were written "on the fly" and really need better argument validation and error checking, but they seem to do the job. Some of these come from the SMO chapter in Dan Sullivan and my "A Developer's Guide to SQL Server 2005 " book. Enjoy!

I'm in Barcelona in TechEd and tomorrow I'm going to be doing a chalk talk on SQL Server Management Objects (SMO). Although I'd usually done my SMO coding in C#, I decided (based on my co-author Dan Sullivan's blog post on the subject) to try out using Powershell along with SMO. So, although when most folks think of SQL "scripts" being lines of code written in T-SQL, with SMO and Powershell the term "SQL scripts" takes on a somewhat different meaning. If you're at TechEd, stop by and we'll write some new-fangled "SQL scripts". Although some things that SMO does actually generate registry changes, the "real" T-SQL equivalents for most things SMO are still available using the SMO scripter.