I'm using a Goggle blog for another project and overall it works fine, no complaints. I've also switched to using Live Writer for blogging, my typing is bad enough that a spell checker is a must (and grammar checker would be a nice addition). Today I was doing a post that included an image, easy enough in LW, just paste it in. When I tried to publish the post it told me I had to log in to Picassa so that I'd have a place for the images. I did that, but not thrilled with that implementation. Why do I need another step other than to drive traffic to another Google site? I just want to upload the image, and if I want to change it, I want to edit the post and change it. I get that the images can be stored anywhere (including Picassa) but it just seems like a bad model, having posts in one place and images in the other. Hide it from me, let me manage it using standard tools, all is good.

Images are always the pain point for these types of applications. Doesn't matter to me if the files are in the file system or a table (though I lean towards tables for DR and security), just make it seamless. LW does its part, Google just tweaked me enough to want to write something down about it!

One of the big themes this year for Microsoft (and I just saw it on the PASS Summit site) is about IT Heroes. Perhaps I'm just hard to live with today, but I don't think there are too many heroes in IT. We work hard, we make a big contribution, but for the most part being in IT isn't glamourous - it's a support role and we tend to get overlooked unless we goof! Language is important to me, I think the words we use mean something, and for me heroes are the members of our armed forces serving in Iraq and Afghanistan, firemen that go into burning buildings, policemen that fight the good fight, etc. If you're in Iraq providing IT support I'll gladly call you a hero. Maybe your definition varies, but when we teach our children about heroes, don't we want to use a better example?

For all my grumping though I think it very easy to feel under appreciated in our business. Sales guys tend (I'm going to stereotype a little here) to be the stars and prima donnas of the business, following by marketing, and then followed by whatever people are actually doing the operations end of hte business. Unless you sell software IT guys are enablers, but just support staff just like the secretary, janitor, plant guy, etc. Business needs them all to run and we shouldn't in a more perfect world treat some as more important than others, but it doesn't work out that way.

But back to under appreciated. Few outside IT really understand the challenges and complexities we face, or understand the impact the work has on us as we try to build things they can use against a spec that makes a mirage seem solid, or understand how hard being on call is on family life, or the many extra hours required to apply patches, upgrade servers, etc, etc. And even within our profession it's easy to get pushed into a reactive mode where on Friday afternoon you look at the todo list from Monday and realize you haven't started it yet. Makes it hard to head home with that 'I had a good week and earned a good weekend' attitude.

I used to work at a teleservices company managing a team of developers and DBA's, with a payroll for my team of more than a million dollars. The entire team was overhead! The 'doers' were people on the phone making $15-$20 an hour. Figure it took a minimum of three people on the phone to pay for having one person on my team. That's 40 people we had to hire and maintain just to afford my team. And would any of us trade what we make for what they make in order to get more recognition?

What that means for most of us is understanding that we may have to fight for some recognition, and that in most cases we just have to understand that our quiet contribution is an important part of the business, but it's not the business, and businesses focus on the people that directly drive revenue.

Not sure I've made my case well, but I'll wrap with this; all employees deserve to be recognized for their contributions, but few employees are heroes. Let's find a different word/way to celebrate our particular contribution to the business world.

If you've ever taken a look at the auto generated statistics that SQL builds (typically on non indexed columns when you reference the column in a where clause) you'll see that they are named _WA_Sys...blahblah. But why? A quick search didn't reveal any good answer (though perhaps I just didn't ask the right question) and in practice why do we care? We never reference the statistics by name unless we're really deep into a problem.

My reason for ranting is based on an event earlier this week. I was doing an adhoc demo to show a new statistic being created via autocreate when I referenced a non-indexed column. It worked fine, but I wanted to show the result - which meant opening up 5 or so wrong ones before I got the right one. Given that the auto created ones are usually (always?) on a single column, would it hurt to name the statistic something more useful - like the column name? So while I'm complaining, why is it that I can view the statistics (same as dbcc showstatistics) via the properties for stats on indexes, but not for 'plain' stats?

Maybe there's a good reason.

I've read with interest some of Steve's editorials about SQL 2005 SP3 and in large part agree with him that it's hard to believe they are contemplating no additional service packs beyond #2. I think it's easy to react - or over react - to the news mainly because we never had a reason NOT to expect more service packs (SQL2K is at SP4) and clearly they are still fixing things. I also get that they are a business and building service packs costs time & money, and presents a degree of risk (see the SP2 fiasco). Asking customers to voice their opinions that a SP3 is disingenuous, most customers are using the product and either not seeing some of the pain or are just living with it (knowingly or unknowingly). They could ask the MVP's, or PASS members, or any other group and I suspect few would argue against additional service packs, but if you weigh that head count against the total, it's a very small sample and easy to call them a special interest. Maybe they'll change their minds or maybe not, but I think what we consumers should be doing is voicing clearly our expectations:

• As long as a product is supported we expect service packs to ship at least every 6 months
• Make it very easy to see the list of hotfixes and to gain access to them
• Commit to fixing bugs because you promised features would work. Its fine to prioritize bugs based on severity and audience impact, but you don't get to skip fixing ANY bug. No bug should be open more than a year from date reported
• We get that products will have bugs, shipping us service packs and hot fixes increases our confidence in the product rather than reducing it

But the same problem applies - how are we going to get that message to MS? Boycott SQL 2008? Switch to MySQL? Here's a time when I wish PASS would take a stand and push on them, but I don't expect that to happen.

Sort of related has been the news that SQL 2008 has slipped until late this year. Again, Steve and others have commented, and I saw this post from Dan Jones that defends the decision to slip. Here's my take:

• MS, the marketing guys are running the train off the cliff. This combined product launch is a joke, better to have a SQL launch - whenever that is - when the product is shipping
• We get that things go wrong and no, we don't want you to release a product that is not ready. But products don't slip six months in a day. If they do, you need new management
• It's not that we're in a hurry for SQL 2008. Looking forward to more features, sure. But many are still digesting SQL 2005 so it's the when that matters, it's that you (MS) are supposed to be the worlds best software developers and it sure doesn't look professional when you can't come close to meeting a schedule. Is it the developers, the sales guys, the marketing guys, all of the above? Don't know and don't really care.
• MS, I get that it's easy to get defensive, heck I would too! But you don't make money by telling your customers they are wrong. How about some much needed transparency around the schedule and features? How about publishing a burn down chart do we can follow along?

As much as the OS, SQL Server needs to be robust. That's job one. But it's not the ONLY job. I make my living on SQL Server right now, like the product, like the people on the SQL team I've met. But I've got to have confidence in you and be able to talk to my customers about your product openly and proudly, or I might have to find a product that does a better job of it. Get out of Redmond, come spend some time with the user groups and regular people - I think you might learn a lot and find that we want you to win.

There's a lot of buzz in the development community about LINQ in general, and for those that do data access just as much buzz about Linq to SQL. It's hard to describe in a sentence, but think of LINQ as a way to write queries against .Net objects using an almost TSQL syntax. Linq to SQL uses that same slightly different syntax to access SQL Server, but it does so by building an object layer (think of ORM) that hides the data access. For those of you that are DBA's, the first thing to know is that nothing changes server side, Linq to SQL still emits the same TSQL we know and love!

I've done enough development to appreciate encapsulation and to realize that writing a lot of the data access code is drudgery. Linq eliminates some of that and makes data access more object oriented, but I think it contains a couple serious flaws and one fixable flaw:

• SERIOUS. It supports stored procedures, but it does NOT encourage them. By default it generates dynamic sql directly against the base tables/views. I get that all tools can be used for good or eveil, but most developers will use the defaults because MS must think that is the best way to do it and because it's just easier to use the defaults (what I call in my classes 'vanilla'). We've spent 10 years trying to explain the benefits of stored procedures for performance, security, and and maintenance, and this could easily set us back years in that effort. At the least I'd like to see them offer a step in the wizard that generates or regenerates stored procedures. Even better is to figure out a way to start with dynamic sql in the early dev stage, then make it easy to create and transition to procs later in the cycle. DBA's, this can be lose-lose. If you stop them using dynamic SQL you spend a lot of time/energy on that fight and just make them mad, and if you don't, well, good luck on explaining to the auditors why everyone has select * access to tables.
• SERIOUS. If you proceed with dynamic sql in the data layer there is another flaw that should make the average DBA feel faint. You will not be able to easily answer the question 'what changed' when something goes wrong. Imagine your dev team making some 'minor' changes to code that has been working fine after your last round of tuning. They deploy and 10 minutes later performance drops sharply - what changed, or is it something else? When they send us proc changes it's a deliberate step in the data access cycle that let's us look at what they are changing, compare to the performance of the existing proc, and to make changes to it or to the supporting indexed to maintain performance. When the entire app uses dynamic sql you'll be back to Profiling to figure out what changed. Remember, all it takes is adding one column to a select to change a plan from one that is nicely covered by an index to one that uses a scan or worse.
• FIXABLE. It actually generates reasonably dynamic sql, at least on 1-2 tables in the examples I've seen. It uses sp_executesql and you would expect to get reuseable plans, but the way they generate it for strings the input params are sized based on actual rather than declared length, so you wind up with x number of variations on the same plan. Not as bad as using Exec(), but still not good. Turns out they do the same wrong thing with stored procedures AND they execute the proc using sp_executesql (for the latter I'm not sure there is much wrong with that approach, but doesn't seem right either). MS should be able to fix this easily.

The good news is that with coaching we can make it work and let the developers keep most of the cool new stuff.

It's funny - sorta - how you become used to the quirks of the tools you. I try not to rant too often here on the blog, but seriously, it's time for TSQL to lose the BEGIN/END syntax. It's clunky syntax that I think adds more bugs than it prevents. Think changing it would break too much code? Just leave the current behavior as the default and build in a SET option, perhaps SET BEGINEND OFF, that we can just add at the beginning of a procedure.

Maybe if we can get that one fixed we can also get ELSEIF?

Maybe someone at MS can explain this; they have that nice dialog that comes up after a reboot where you select planned/unplanned, enter a code and a reason. Why don't they auto populate that when a Windows update triggers the reboot without user intervention? A list of the changes applied would sure be sweet to have in the event log.

If you do any coding in .Net using aspx pages you'll recognize this one. Each page has a title attribute that defaults to 'untitled page'. Nothing wrong with a default, but I sure wish they wouldn't let those pages compile or would at least flag a warning. All too often I run across simple sites where the title in the browser is 'untitled page'! Heck, I probably have one on one of our sites somewhere, but I try to always check. Now when you see it you'll know why it's there.

MS includes a bunch of reasonably nice validation controls in VS 2005 and one of them includes the ability to validate that a string is a valid (syntactically) a URL. Sort of. If you don't prefix it with 'http://', it says it's invalid. I'd argue that we could just assume it's supposed to be there, but I guess erring on the side of caution is ok. But today, I was just about to post a link on www.opass.org about http://support.microsoft.com/default.aspx?scid=kb;en-us;912914&sd=rss&spid=2855 and the stupid control says it is not a valid URL, yet clearly I can browse to it! Possibly I'm missing some service pack, hot fix, or super secret turbo switch. Then again, maybe the MSDN guys don't use their own controls?