Tom Moreau is a SQL Server MVP and has been since 2001. Writes a regular column called “Dr. Tom’s workshop.” Began back in January 2001. Written lots of articles all over the place; now is working on some articles right now. Best known for co-authoring the Advanced Transact SQL for SQL Server 2000 with Itzik Ben-Gan.
Greg Low: Introducing show number 11 with guest, Tom Moreau.
Our guest this evening is Dr. Tom Moreau. Tom is a SQL Server MVP and has been since 2001. Writes a regular column called “Dr. Tom’s workshop.” Began back in January 2001. Written lots of articles all over the place; now is working on some articles right now. Best known for co-authoring the Advanced Transact SQL for SQL Server 2000 with Itzik Ben-Gan. Welcome Tom.
Tom Moreau: Hi. Based in cold up here.
Greg Low: It’s certainly not cold here; I’m in Brisbane at the moment. You use Celsius as well, we’re about 36 today.
Tom Moreau: Oh!
Greg Low: Getting up towards September here for the folk in the U.S. We might start; tell me how you came to be involved with SQL Server in the first place? A bit about your background?
Tom Moreau: Before I started playing with SQL Server I was playing with DB2 for about a year and a half. Job opportunity came up; I didn’t have any SQL Server background at all, but because I have some SQL background they took me on. Back in 1993. It was SQL Server on OS2. One of the oldest versions of SQL Server we had. You installed it with four floppy discs, that kind of thing. After being at that firm for about two years I became a consultant. I ramped up on SQL Server fairly rapidly. I became a consultant much to the urging of my wife; wanted me to become a consultant a long time before then.
Greg Low: Interesting, wives usually want you to have a permanent job with a permanent income.
Tom Moreau: When we met, she was in flying school and I was already a pilot. She was already a consultant way back then and I was a graduate student. I was of the feeling that I wanted to be a permanent employee and work for someone else. She’s very independent. It rubbed off; her confidence wore off on me. She was the one who told me what a database was, what normalization was; didn’t start life as an IT guy. My degrees are in electro physics and space science. One thing I learned early as a scientist is there’s no money in scientific research. I had to make a career change. Through my graduate school I was doing a lot of computing and analyzing data. Dianne would get several calls a day, cries for help; mainframe programming at the time. She would ask “what’s wrong this time?” “I have an OC-4.” “You have to do this.” That’s how that began. Back to SQL Server, my first contract lasted almost two years. I learned a lot.
Greg Low: Mostly doing DBA work or developer work?
Tom Moreau: DBA. Up here DBA does a lot of things, you can’t just be an administrator really. Design, implement, and administer, that sort of thing. A lot of what I did then and what I do now is what I call janitorial programming. Cleaning up someone else’s mess. That assignment was a lot of janitorial programming. How not to.
Greg Low: Interesting in the industry that everyone talks about cleaning up somebody else’s mess. No one says “I go around making the mess.”
Tom Moreau: Oh no, nobody makes messes. Bless them all, it’s been lucrative for me.
Greg Low: How did you come to join the SQL MVP group?
Tom Moreau: I had already co-authored the book with Itzik Ben-Gan. I had been active in the Usenet newsgroups. My editor, Cara Waterson had asked “what does it take to become an MVP? Tom does a lot of stuff, he never gets asked.” Very active in the newsgroups. I was practically living there. What I found out is it’s the Microsoft newsgroups they want you to be active in. My ISP didn’t have a DTS newsgroup. I went to Microsoft DTS; they had everything else there. I hung out there and did my normal fielding of questions. Email from Steve “would you like to be an MVP?” Sure! That’s how that all began.
Greg Low: So I must admit, noting in the discussions you’ve had in the MVP newsgroups lately, having lots of discussions on Service Broker. Obviously an area of interest at the moment?
Tom Moreau: Oh yeah. Very much. I’ve done multi-threaded programming before, and in fact before I became a DBA I had done presentation manager programming. I know what a Win-proc looks like. I look at this stuff, it’s similar but different. The fact you can multi-thread this stuff, this is really gold. It’s what I call DBA candy.
Greg Low: I must admit, Service Broker still seems to be one of the least understood aspects of the product. I think it’s largely because it’s brand new; there was no equivalent before. Where do you see the sweet spot for using Service Broker?
Tom Moreau: It’s hard to define a sweet spot per se. If you have an application that can be broken up into bite-sized chunks; humans don’t eat a meal in one bite. If you can take a piece of work and break it down so the stuff that absolutely positively has to be done as a single chunk. I’m not thinking in terms of transactions. What we did use sort of a real-world example of what happened to me on an assignment that I had. A year and a half ago. This is to do with police database. Everything gets audited, everything they do. This application, the audit trail was done in flat files; wasn’t done in a database. Everything that went to the database was in the database. We had to analyze these files, do it in an efficient manner. I ended up writing multi-threaded proc script to do it all. Once you kicked it up there was nothing for you to do but twiddle your thumbs; wait for files to come in. What would happen is the output from this stuff would spit out files if it found anything. It was a multi-threaded sniff of audit logs. It’s the type of thing I wouldn’t want to wait until the whole thing got done before I started to see the first file come out. I wanted to see it as it was occurring. Let’s say you had everything in the database; you wanted it to start sniffing through chunks. You could issue messages and every time it found something, send you a message back saying “this is what I found.” That kind of thing. This would be great if I had that capability back then.
Greg Low: One of the things we discussed when I was doing some research for the show; turned out we’d both been reviewing and looking at two of the same books in recent times. One of the ones Bob Bachman and Dan Sullivan’s new book that replaces the “A first look at SQL Server 2005 for developers.” For listeners, they should keep an eye out for that. People need to save their pennies; this really will be almost like one of the new bibles when it appears. One of the things I quite liked that Dan Sullivan did in one of the sections he was talking about uses for Service Broker. Why it needs to exist. He was talking about the fact that if you take existing tasks like if I arrived somewhere at a wholesaler and wanted to place an order at the counter. Typically the person who deals with me doesn’t then run off downstairs and look to see if the item is there; parcel it off, send it, do the whole process. Tends to be there’s some form of things like documentation of the person at the counter completes; passes it on to someone else who then does the next part of the work. Making the analogy that almost what we do with stored-procs today, we do the entire process inside the proc. That’s one of the things that when I think about it; limits the scalability of what we can do with the systems. As soon as you can introduce a transacted queue into the way things are done, you can much more spread it out across different servers, is that how you see?
Tom Moreau: You could spread it out across servers if it was that type of thing. What I like to be able to do is anything that can be done in parallel. I like to be able to do that. For example I could flick off… Let me give you another real-world example. My current client I saw this through a profiler and said “it’s too bad they don’t have Service Broker.” They were deleting from three different tables, it would take 20 seconds, all they were concerned about was that those three tables had those deletes done. It does one delete, then another, then another. Why can’t it be done in parallel? A Service Broker application would cue those deletes by sending messages to three separate queues. Let the thing run; once all those three are done then you can go forward from there. If you had to wait. Is what you’re interested is just getting them deleted? Fire and forget; we’ll talk about those later. You should fire, but never forget.
Greg Low: I think that’s one of the things people really have to get their heads around a little bit; the whole idea that you don’t necessarily want to do all the processing synchronously. Ask the question; hang on and wait for the answer to come back. May have to go with a flow where I start something and am confident that it will let me know that it completed it or something occurred.
Tom Moreau: That’s the way to do it now. Not every application is amenable to doing that. If you truly have to get a result when the process acts is done; you’re going to say with your existing T-SQL proc, the way it’s been architected. If it’s something that can be spun off, and all you really need right now is an acknowledgement. That’s a potential candidate for Service Broker.
Greg Low: So, as you’ve been going through, I know you’ve been preparing an article for MSDN magazine?
Tom Moreau: For SQL pro.
Greg Low: Oh, for SQL pro. To do with Service Broker, when you’ve been building Service Broker applications. I presume you would’ve found a number of surprises along the way as to how I thought I knew how it worked; but it didn’t quite work that way. What things did you learn that surprised you at all?
Tom Moreau: Just getting my head around the paradigm shift. Yeah, okay, I’ve had some multi-threaded background; played with messages. This is new technology to us in the SQL Server arena. It’s different than learning T-SQL. The example I’d like to give you is it’s easy enough to teach somebody how to write a select. Select start from my table; that’s pretty simple. We haven’t talked about the ware-clause. We now talk about the ware-clause; you filtering it. Talk about removing the start; individual columns. I can build a little bit, but I can get functional right away. I can’t do that with Service Broker. There are many things that I have to know simultaneously before I can get started. It’s so easy to mess things up and get lost. It takes reading and re-reading and re-reading. I read Bob Bachman’s and Neil’s and Dan’s “First Look” book. Very helpful. Got some hands-on when the betas were coming out. Kind of put it away for a while, when I got back to it after the RTM version came out. I’ve done a mini-technical review on Roger Wolter’s book. He’s updating it for RTM as well. Unfortunately I didn’t read that book until after I read my article and had my nose bloodied by then.
Greg Low: We could focus on that book in particular; I have been working with Service Broker for quite a while. For the last year and a half at least; teaching developer classes for SQL Server 2005 where I thought we tried pretty much all of the things that happened with Service Broker. A few weeks back I finally got to sit down and read Roger’s book. It opened a number of windows for me and doors that I had no idea. I think really strongly recommend to people to have a look at Roger Wolter’s book on Service Broker. Rational Press; not a huge book to read. I think the thing that I’ve found is that there were numerous insights in it that only somebody in the product group could come up with. The best example I’ve got of that is I was trying to get my head around why there was a concept of a conversation and a dialogue in the fact that the two were different. Roger pointed out that there was also planning for a concept of a monologue. Things like that; only somebody in the group could really come up with that sort of thing.
Tom Moreau: That’s true. Where I really screwed up was the idea of sending from the service to a service. I thought okay, the services can talk, but how do I get that first message going? I was thinking in terms of fire and forget. That’s what messed me up, this idea that while you should be expecting some sort of message traffic coming back from once you sent it. I thought alright. It took me a while to get straightened out on that as well.
Greg Low: I remember you were having some discussion also; things you found about end dialogue?
Tom Moreau: Oh god. Yeah, I’m getting cold sweats right now that you brought it up.
Greg Low: What happened there?
Tom Moreau: This is the thing. When you are trying to de-bug something that is either multi-threaded or asynchronous, it’s difficult to say “what happened first and what happened second and what happened third?” For the life of me my activation proc, I had my “if” statement in there to look for my end dialogue; big ugly URI. It’s like the thing evaporated. I didn’t understand where it was going. What I ended up doing, I would select from the queue; I can see the thing in the queue. My loop where I’m doing the receive didn’t seem to be there. I finally found out that there was an end dialogue in there somewhere that I hadn’t accounted for. I said “oh, ok, I’m getting it now.” Originally I wasn’t even… I had a problem understanding this idea of who ends what. I thought once an end dialogue has been issued once that’s it; you don’t have to do anything. That’s completely wrong. The way I like to relate it to people is “you call me on a telephone and I answer. We have a conversation and we exchange messages. At the end I hang up and you hang up. Not one of us hangs up, we both hang up.” That’s where I got hung up.
Greg Low: Another thing I found I like in Roger’s book. He had a description about the pattern that you might use for a receive loop. The idea, I see a lot of people starting to implement Service Broker, try to have an activation proc that’s fired up for each message. Having it process that one message and then exit. He really makes a strong case for not doing that. When the activation proc gets fired up the idea is to process what’s in the queue; hang around for a period of time to see if anything else is in the queue. If something doesn’t appear in the queue for a little bit of time, then exit the proc. Keep the proc running while there are things appearing in the queue.
Tom Moreau: I’ve got that pretty much standard. I’ll put a five-second time limit on the thing. Only at that point do you truly haven’t received anything, there must not be anything in the queue for you to process. Coming back to this end-dialogue scare I gave myself; I have a philosophy on when to issue the first end-dialogue. Say you have service A and service B. Service A needs work from service B. Begins dialogue and sends message across. Service B does it work and sends a message over “yeah, I did that for you.” And now these two guys have got to end their dialogue. It’s possible that service A sends the end dialogue after receiving that message. Service B ends his dialogue. With something like that if you’ve got queues that are not busy, and the work took a while on each side; it’s possible that there is no currently running activation proc on a given side when the end dialogue comes across. Then it has to fire it up. The approach that I would like to take is whoever first detects that there really is no need for further communication. You send that last message and immediately follow that up with your end dialogue. They’ll both get processed together when they go across. More than likely. It’s incumbent upon the other guy to acknowledge the end dialogue; send that across as opposed to doing it the other way around. Played with it long enough now to have a philosophy. That’s it.
Greg Low: That’s great. That might be a good moment to take a break for a few minutes. We’ll get back after the break.
Tom Moreau: Cool.
Greg Low: Can I just get you to tell us anything you’re willing to share about where you live, what you do, what you’re keen on?
Tom Moreau: Well, right now… I guess we already said that I was doing consulting; assortment of assignments. Most of them are like a full-time gig. Did that for a few months; working five days a week. With Yukon hitting the streets and me not having as much time as I wanted to dedicate to it. Wanted to take a couple days to play with Yukon and get up to speed. It’s a big milestone release. You’re not going to learn anything very quickly. Two days a week are my Yukon days and three days a week are my consulting days. What’s good is that because I’m doing this at home I can also multi-thread my stuff. Get some domestic chores done so on the weekend they are ours to go flying in Ontario.
Greg Low: You actually fly and Dianne flies as well doesn’t she?
Tom Moreau: That’s right, we met at an airport. I fell in love with her as soon as I saw her. I thought “I want one of those.” I rented the best airplane they had and took her on a flight; let her fly from the right-hand seat. It worked well. Eventually when we had the opportunity to buy shares in an airplane; we did. We took that airplane on our honeymoon. I even did a flight test because the flight test had been delayed. Did that on the honeymoon. We eventually bought out our partners, we owned the plane outright. We try to fly it as often as we can.
Greg Low: Noticed in your material also you’re in to guide dogs for the blind; volunteer work in a wildlife center as well?
Tom Moreau: I’ve had a soft spot in my heart for guide dogs, specifically ones for the blind. Also hearing ear dogs and what we call special skills dogs for people in wheelchairs. You won’t believe what these dogs are capable of doing. The difference they make you can’t describe. Mobility, freedom. My initial dream was to get a guide dog. Female golden retriever, wanted her to be named Freedom. We’ve had some ups and downs trying to get Freedom. We’ve had another dog graduate before her. Part of the problem with freedom is that with guide dogs many are called and few are chosen. There are many opportunities for them not to make it. We have run Freedom #4 right now. We’re hoping that Freedom #4 will graduate. You don’t know the one called Indiana who graduated last summer. He’s doing very well.
Greg Low: With the work of the wildlife center, Birds of Prey, is there some interest there from your flying interest as well?
Tom Moreau: I’m interested in anything that flies; I’m an animal lover by nature. There was a peregrine falcon nest next door to where I live. Condo tower on the 20th floor. Office tower next to us, the peregrine falcons chose to next there. We joined an organization that kept watch on them and so forth. Through that organization we make contact with the wildlife center. Originally helped at one wildlife center. You’re handling the birds, feeding them, cleaning their pens. Tags on their ankles so we when we have the birds on the first they can’t fly away. Lease tied to the jesses. We have to adjust them. Sometimes their feet get infected. They’re wearing very sharp weapons on the end of their toes. They’re called talons. Sometimes when they’re walking around the toe will bend and the point of the talon will penetrate the foot. They’re walking around in their own doo doo; that can get infected. Hold a bird while they’re getting antibiotic treatment on their feet.
Greg Low: Back with SQL Service Broker. One of the things that’s difficult with something that has background activation processes. How did you troubleshoot it? How did you get to the bottom of what’s going on when things don’t do what you’re expecting?
Tom Moreau: I am so glad that Microsoft came up with all these DMVs and Dynamic Management Views. Views that aren’t necessarily dynamic; there to support what you have. You have to do a lot of sniffing around in the olden days. It was good back then, it wasn’t very good. Now we’ve reached the point being very good.
Greg Low: I should get you to spend a moment explaining what Dynamic Management Views are, too.
Tom Moreau: They hook into what’s going on inside the SQL Server route. The views are not necessarily on real cables, a lot of them aren’t. Things are, as the name implies, dynamic. If you want to look back to your SQL 2000 and older days. Remember the table processes. That’s not a real table, it’s a virtual table; it’s all memory. Your Dynamic Management Views can work the same way there. What I was doing, trying to troubleshoot why I didn’t even get a message in my view is to do a select-star from your queue. It’s non-destructive; you can select-star as many times as you want, you won’t hurt the data. The receipt is a destructive select, it reads and deletes at the same time.
Greg Low: A select can also have complex ware-clauses associated with the queue; receipt has very limited options in terms of…
Tom Moreau: That’s true. If you’re just doing your select-star lease, you can see if there’s anything there. That’s step one. If step one doesn’t work you’re wondering what has happened here. Then your next ally is sys-doc-transmission queue. Things go through there if they can’t get dropped into your queue. In my upcoming article what I refer to it as your dead letter office. You sent the message, it went somewhere, that’s where it went. You can see some of the information that’s related to it in there. In my case it was there and I was going “okay, I created the queue, what’s going on here?” Low and behold, Microsoft is taking security very seriously. I hadn’t created a database master key.
Greg Low: That’s one that I fell for too. It’s something that changed since the more recent betas prior to release. I had demo code I had built up that I had been using for the last year and a half. I know when we went to do the SQL launch events recently. I went to use that same code; it simply wouldn’t work. I was sitting talking to Peter Myers, one of the local SQL trainers about it. Looking through, couldn’t see anything we had done wrong at all. It now did require that master key to have been created in the database. Previously, ironically, we happened to have done some encryption demos beforehand. It happened to be there. The Service Broker ones on their own, that’s the sort of thing. It can make you sit and stare and wonder what’s going on.
Tom Moreau: I knew that I had enabled Service Broker on the database, that’s another thing you have to do. Enable it as well as create your database master key. It doesn’t work by default. You do have to turn it on and make sure you’ve got that master key. Once the master key was on at least I could see stuff going into my queues; I was a happy camper on that.
Greg Low: The fact that it shipped not working, too. People should note there are several other things that are dependent on it. Query notifications, new database, so on. Layers of software that sit over the top of Service Broker. Even though it ships not running I suspect many people will end up with it running regardless.
Tom Moreau: I can’t see turning this off or leaving it off. It’s a strong technology; you’re going to take advantage of it sooner or later.
Greg Low: Which of the DMVs did you find useful when trying to work with this?
Tom Moreau: That transmission queue got me past the first term. Fortunately, being an MVP I can post prize for help in the private MVP newsgroups. Roger Wolter from Microsoft hangs out there a lot; he’s been very helpful. Once I got past that, some of the other views…. For example there’s one called sys.DM Broker queue monitors. This one is cool, shows you information on individual queues. For example, it’ll show when it was last activated. I should warn the users I learned this one the hard way. The last activated time that you see in there is DMT. Living in Toronto, I was able to pick that up fairly quickly; we’re GMT minus five. Last activated time, that’s five hours from now. Oh, I get it. You in Brisbane are 10 hours ahead. It hasn’t been activated in 10 hours? You can see what’s going on there. It will tell you the number of tasks waiting; you can see if there’s things that are queued up. Another thing there is a database ID. You’ll want to filter that on your own DBIT. See other traffic that’s in there. Another thing you’ll want to do is make sure you’re running… When you do the select, run it inside your own database. One thing you’re surely going to want to put up there is the object name of the QAB. It’s not there by default. All you have are numbers. Unless you’re good at memorizing the object ID of your queue, it’s going to be meaningless to you. Another one that… This is one that really revealed a lot of things to me. Its sys-doc conversation endpoints. This is where individual conversations show up in there. You’re not getting the text and the individual messages, but you’re seeing the state that the conversation is in. You can see that it’s open or closed. If one side is disconnected but the other side is not. When I was going through all that grief with the ending of conversations and being under the impression that only one side had to end it, I would see these IDs show up. That’s disconnected inbound. One half of the requirement was met and the other one wasn’t. I didn’t know what it was telling me. I posted that in the pages group. Once again Roger Wolter swooped in and said you have to close the other half.
Greg Low: That’s something also that people might have to get their head around. The idea that these conversations can also span very long periods of time. In fact, I think in Dan Sullivan’s book, he describes the whole thing as a saga. It could be years; that wouldn’t be the normal case. Certainly the fact that something hasn’t ended within a few minutes is really not an issue. The system is more than happy for it to go on for a very long period of time.
Tom Moreau: It’s not necessarily a bad thing. In Roger’s book, the example he gave is let’s say you order an airliner from Boeing. Certain events occur like materials get ordered and so forth. It takes a while to build an airliner. They don’t work the speed of the Internet. That kind of conversation could last a long period of time.
Greg Low: I went to the tour of the Boeing factory. I have to say that was an entertaining thing to go and do. Ten months from beginning to end from the point you ordered it to you have a 747-400 come out the other end.
Tom Moreau: If your Service Broker application was for that kind of process then the conversation isn’t going to be closed until months down the line. Just because it’s not closed doesn’t mean it’s necessarily a bad thing. What it requires is intimate knowledge of your application. In my application I knew these things should’ve run a whole lot quicker than that. Why are they still open? Once they’re closed they hang around for a while in that queue. That’s something that bothered me. I figured well you’re closed, you should be gone. Roger said they do hang around for a bit. Restarted the machine I’m using virtual machines… When I restarted my virtual machines, all of those conversations were gone when I started it back up again.
Greg Low: Most of it. I did have to stop and think for a minute about the idea that the conversations could really go on for that length of time. That’s right; many processes may take quite a long time to complete. With other things that have been added to the product in this release in SQL Server 2005, are there any other straight stand-out things that you found helpful? Things you’ve been exploring lately?
Tom Moreau: Haven’t limited myself to Service Broker. Service Broker is my latest narcotic I’m addicted to. Those of you who read my articles probably see more of a T-SQL theme. I jumped onto that the same Itzik jumped on. I’ve done a few articles now on the CTEs, common table expressions. Those have an awful lot of power. For example. Hierarchies prior to this time, it was a work around it. There was nothing in the relational model that supports a hierarchy. You can put things in there where you have a parent and child. Parent ID and child ID in a table. Hook them up, but to come up with the results you’re after are a pain. Itzik and I wrote the book; he wrote the entire chapter on hierarchies, and put together a lovely way of doing it. You have to modify your table in order to manage it properly. With the CTEs that’s all gone; you can just manage them out of the box. The first article that I did wasn’t on hierarchies, but was on a routing problem. More to do with brass than anything else. I was inspired by… Waiting at an airport for my plane to arrive, I thought “well, airlines have to manage getting you from A to B. When you book an airline flight you want to get from A to B, you don’t want to go through too many hops in order to get there.” What I did, I can’t remember the month in which I published this one. But if you got to the SQL Pro website, it’s looking at airline routing and you want to limit yourself to no more than three hops. Show me all of these flights going between Toronto and Seattle. Consider this: I could go from Toronto to Boston, Boston to Toronto, and Toronto to Seattle. Three hops. I don’t want to make a flight like that. Make sure there’s no cycles.
Greg Low: I think I’ve been booked on airlines that have tried to do that to me.
Tom Moreau: That’s called a cycle. You have to prevent the cycles. You have to keep track of where you’ve been on each iteration of your CTE in the case of using an iterative CTE. You can put it all together, I was pretty happy with that; I thought that was pretty cool. My latest CTE article was either last month or the month before; that was to do with… Maybe it’s this month, I lose track. I’ve written over 100 of these things. This is basically managing referential integrity. Even though SQL 2005 is very powerful, if you were to put a referential integrity constraint on a table that had a self-referencing table. You can put a foreign key on there. If you put on delete cascade it will blow on you. Say “potential cycles,” whatever it is; cyclic issue there. You have to end up doing that with triggers. You can do it with triggers but with CTEs. That gets you; you can manage it that way. Then you’re fine.
Greg Low: That’s great. I’ll be looking forward to what Itzik’s got coming up with that regard. He’s been discussing a bit lately about the idea that you can update virus CTE also. Discussion in the groups as to whether or not that’s an AT-compliant thing to be doing or not. It’s an interesting use of the CTEs.
Tom Moreau: I’m not a purist when it comes to An-C. There’s a lot of stuff in SQL Server that’s not An-C. We have proprietary stuff, thank goodness it’s there. It helps solve a problem from that.
Greg Low: That pretty much brings us to time. What I’ll get you to do is tell us what’s coming up in your world, what can we look forward to seeing? Coming from what you’ve written, places you’re speaking?
Tom Moreau: I had taken a hiatus from speaking for quite a while. I guess I’ve been speaking 1999, 2000, 2001. Haven’t really had the time or inclination. Now that 2005 has been released, I’m more inclined to do that. Certainly locally I’ve been going to a number of Microsoft events where they have “ask the expert” booths. MVPs like to come up to that and talk to people; I was here for the product launch. Very busy, didn’t get to go to any of the breakout sessions; I was answering questions all the time. Like to get back into that. My monthly columns, because I have Mondays and Tuesdays to work on Yukon stuff. I’m going to try and crank out some more articles on that. That’s what’s on my plate for the next while. At my client we’re going to be putting together a customer now. It’s not SQL Server 2005; it’ll be SQL Server 2000. They want to wait until Service Pack One has been released.
Greg Low: One of the challenges; the database community by their nature tend to be fairly conservative. In many cases it’s a warranted thing. I know one of the things we’re looking at running locally, assuming a series of upgrade-related sessions; discussing exactly that. Is that something you should be looking at upgrading now? What’s the advantage? Understandable in the database community, you tend to be conservative.
Tom Moreau: Interesting you should mention. Microsoft is their own worst competition here. SQL Server 2000 is a very good product. Even 7.0 was a good product. You have stability, performance, that sort of thing. The stuff like Service Broker is very cool; but is it something you absolutely have to have right now in order to make your application run? In some cases yes in some cases no. Where you’re going to see it get more adoption is if people are building new applications. They’ll say “ok, we’re starting with a clean sheet here, what do we have at our fingertips?” You’d be a fool not to go with SQL Server 2005.
Greg Low: It’s a tool in your toolbox. If you’re doing a straight upgrade some of those things aren’t necessarily things you’re going to take advantage of. One of the sessions I enjoyed at PASS conference in Dallas was Don Vilen’s session. At the time it was called “transparent upgrade benefits.” Discussed if you just upgrade; here are all the things that juts work better. I must admit I really enjoyed that session.
Tom Moreau: I was in that one as well.
Greg Low: That’s right, I recall you. You were sitting in the front row with me. Anyway, thanks for your time today, Tom. We’ll talk again soon.
Tom Moreau: I sure hope so; I’m looking forward to it.
Greg Low: Great, thank you.