I’m going to combine days two and three into one big entry because I
don’t think I’ll get a chance to do a full day-three review at the end
of today.
Yesterday was day two and we looked at SQL Server 2005 service broker
stuff, its native HTTP support, and Notification Services.
The service broker facilities they’ve added are pretty cool. The
ability to set up messages and queues and such inside the server is
neat, and it folds nicely into the native HTTP support to allow for
exposure of these things via web service. Cool. SQLXML has rolled into
SQL Server, which we all anticipated and love.
Notification Services, though… OK, I’m just going to be brutally
honest:
SQL Server 2005 Notification Services sucks big fat donkey dong.
Seriously.
Notification Services is the biggest hunk of claptrap Rube Goldberg
mechanics I’ve been introduced to in a long time. It’s not debuggable,
it’s super-hard to set up, and for what it offers I’m not sure it’s
worth the effort.
We had a lab to set up some rudimentary Notification Services. The lab
involved us creating a lot of hand-cranked XML configuration, running
some setup to get the services up and running, then testing it out.
Problem 1: The XML contains SQL that turns into stored procedures. Why
is that bad? When they make the stored procedures, there’s nothing to
tell you whether you have a typo in the SQL. I mistyped a database
object name and it never had a problem with it. In fact, I found that
error in the Event Viewer - not even in the SQL error log - and only
when it actually tried to execute the procedure. NO!
Problem 2: There’s insufficient logging. After I corrected my error, I
tried to use the service again and something else went wrong. What
happened? I have no idea. It just swallows the errors and moves on like
there’s no issue. No errors, no warnings, no log. How am I supposed to
debug that?
The whole thing where the XML that you have to hand-generate (and
there’s a LOT) has a lot of magic words in it that you just have to sort
of “know” about (like you have to just “know” that when you type “Foo”
in one element that it becomes a stored proc with a name like
“ServiceFooSomeProcNameHere” - yeah, that’s intuitive. It really does
work like Rube Goldberg machines - this bit of XML kicks this block of
code out that rolls down the hill and knocks this table row down and
flips over and tosses a message over to that service… Come on, guys.
It’s like someone took a weekend, architected the thing, and clamped it
on the side of SQL Server 2005 so they could have a selling point or
something.
Today we’ll be learning about managed code in SQL Server 2005, which
looks great; working with client apps (ADO.NET), which won’t be news for
me; and SQL management objects, which also looks great.
Oh, and before I forget, tomorrow is Thanksgiving, so Happy
Thanksgiving to all!