I've been honing my slides and polishing up my demos for TechEd 2006 Hong Kong at the end of September. I'll be doing some breakouts there on SQL Server 2005 and ADO.NET vNext, but there will also be a "Day of SQL Server 2005 for Developers", as a preconference presentation. There's so much that's new in SQL Server 2005 that it's impossible to fit it all in a single day, but I think that even if you were at last year's TechEd, you'll be pleasently surprised at some at the newer in-depth material from a slightly different perspective. It will be a FULL day.

By the looks of the speaker list, I'll be in good company in the SQL Server space, with experts such as Paul Randal (check out his latest amazing entries on the SQL Server Storage Engine blog) and Thierry D'Hers. And my old cohort Jon Flanders will be there too, captivating attendees with Windows Workflow Foundation and Biztalk, no doubt.

It will be good to see old friends again, too. Stop by and say hi. See you in Hong Kong!

You've read the specs. Now get the bits. Here. Note that "vNext" isn't V3.0, which doesn't include these new ADO.NET items. vNext is the release after V3.0. Maybe V4?

When I first heard about it, I didn't think the DEFAULT contract in Service Broker had the potential to cause confusion. Goes to show what I know. The problem comes up when you assume "no specification" means "use DEFAULT". Not always...

Service Broker contracts indicate which message types can be sent from the conversation initiator, which message types from the conversation target, and which message types from both/either. Service Broker contains a DEFAULT message type (Validation=None) which is a real message type. The DEFAULT contract indicates that the DEFAULT message type (but no other message types) can be sent by ALL.

Here's the possibly confusing bit. On the target side (ie the receiver of the initial message in a conversation), the contract is specified on CREATE SERVICE.

CREATE SERVICE mytarget ON QUEUE myqueue
 (contract1, -- list of supported contracts
  contract2,
  contract3,
  [DEFAULT]  -- we need this, if we want to use DEFAULT
 )

CREATE SERVICE mytarget2 ON QUEUE myqueue2 -- no contract at all supported 
                                                                   -- not even DEFAULT

Leaving out the [DEFAULT] contract here means the target can't use it. You need to specify it.

For the initiator side (ie the sender of the initial message in a conversation) the contract is specified on BEGIN DIALOG.

CREATE SERVICE myinitiator ON QUEUE myqueue_init -- no contract needed here

BEGIN DIALOG @handle
 FROM SERVICE myinitiator
 TO SERVICE 'mytarget'
-- ON CONTRACT [DEFAULT] -- not needed

However, in BEGIN DIALOG you CAN leave out the contract, and this does mean we're using the DEFAULT contract.

Also, sending a message using a message type, leaving out the message type means you're using the [DEFAULT] message.

SEND ON CONVERSATION @handle
-- MESSAGE TYPE [DEFAULT] -- not needed
  ('Hello World')

Got it? DEFAULT message type and contract are the default, except on the target CREATE SERVICE, where its not a default.

I got email today notifying me that Dan Sullivan and my new book on SQL Server, "A Programmer's Guide to SQL Server 2005" is on sale on Bookpol.com at a deep discount for a limited time only. Check out http://www.bookpool.com/ct/214. I just did and, geez, its better than my *author* discount when I buy 'em direct from A/W. How DO they do it?

I came across a new article, "Data Access Tracing In SQL Server 2005" at MSDN and I'm listed as one of the authors. That's interesting, as I didn't remember writing it :-) but upon closer inspection, they give me credit because they leveraged my original article "Tracing Data Access" from the ADO.NET 2.0 series. Thanks Jennifer and Acey, now I remember you asking if that was OK. I did notice they still used an old bio for me though, just ignore that part.

Anyhow, it's an excellent paper. They added one-third more pages and even included MOF files for tracing JDBC/XA, BCP, SQL Browser, and more. Very cool. Be sure to give it a read and practice your tracing BEFORE you need to use it. 

Sometimes I'll have these interesting juxtapositions of two or more projects I'm working on at the same time. So what does Joe Celko have to do with the Visual Studio "Data Dude" (VSTSDD for short, I don't know what the official acronym is yet) product? Well...

The first time I generated test data with VSTSDD, I was kind of surprised because it was SO random. Odd conglomerations of characters covering every bit of a data type's value space. I was used to more "regular" test data, like...

I'd once worked on a VISA card system in the 80s that had about 100 or so completely made up test customers with real-sounding names. We'd run system tests (15 cycles if I remember correctly) that generated a few boxes of green-bar reports. BUT. The made up customers *had histories* so real that our users (who actually read the test reports) knew them better than our real customers. They could tell, for example that if "Fred Anderson" didn't go over his credit-limit on cycle 12, there was a problem with our latest change on the test system. REALLY.

I couldn't see how any users would remember test names that consisted of 25 "random edge-of-the-value-range characters". I know you can write your own test data generator, but, I was a bit disappointed. At first.

So I'm reading Joe's book "SQL Programming Style". Rules 3.8.1 and 3.8.2: "Consider range constraints for numeric values." And. "Consider LIKE and SIMILAR TO constraints for character values." Hmmm...

So, although the test "names" aren't particularly memorable, they exercise the ENTIRE allowed value space, preventing surprises in the case where someone has a name containing edge cases of characters, or numeric values at the end of the range. Forcing the needed constraints or procedure corrections. Great!

Because... (back to the book) "Look at the actual DDL and see how often you find this constraint. Programmers are lazy and do not bother with this level of details".

Not any more, I guess.

I'd like to see how our users would have pronounced those character combinations and numeric values. Or they'd never encounter them because of proper constraints. Very cool.

Just got back from the SQLskills Immersion event in Chicago. There were a couple of bonus sessions, with Kimberly doing a high-availability talk for Microsoft customers and our students one evening, and Joe Celko making an appearance on Wedsnesday. Joe spoke on elements of SQL style, and I was able to acquire a signed copy of his new (but not his latest) book "Joe Celko's SQL Programming Style". He's also just released a book on analytics since the style book.

With all the weary smiles at dinner on Thursday, I got the idea that everyone in attendence had a good time and was full to overflowing with the topics we presented. If this sounds interesting to you, there are some spaces in our October event in NYC.

An interesting question that came up at dinner was "how do you motivate use of the Service Broker in SQL Server and how mainstream are the use cases"? Here's how.

If you've ever purchased anything on the web, you'll notice that no matter how popular the website, once you navigate through the catalog, fill out the forms with your personal, shipping, and credit info, the actual order screen is quite quick. You get back an acknowledgement very quickly, but it usually only consists of an "echo" of a subset of the data you entered and an order ID. Also, there is likely a hyperlink where you can check the status of your order. Perhaps an email is sent.

Bet they didn't do a credit check, set up billing, shipping, check inventory, and consult the MRP system for a manufacturing schedule while you were waiting, did they? Most or all of this is done asynchronously, probably with queued messages of some sort. Otherwise, it would be quite a transaction, and if all subsystems weren't on the same instance, a (slower) distributed transaction at that.

Generating an order number, saving the order details (maybe in XML format, for later decomposition into the relevent relational tables), and updating/checking the customer table is much faster. And, if the queueing system is inside the database, your queued messages and database updates will be a fast *local* transaction. If you need to save state, you're already in the "state machine/DBMS", rather than one tier or more away. BTW, if you're using SQL Server's Database Mail feature, the email is also sent asynchronously using Service Broker. Gotta save on that synchronous distributed processing. Else you'll get impatient and push "Buy" again. Or perhaps not return next purchase. 

That's the motivation.

We had some very talented technical reviewers for our "Programmer's Guide to SQL Server 2005" book. Some of them, like Greg Low and Roger Wolter, are well known in the blogging community.

I was happy to see that John Huschka and Jens Süßmeyer are both blogging. Jens has been blogging for a few months and has been posting screencasts too; John just started this week. These guys should have some interesting insights into SQL Server 2005 and related subjects. Subscribed!