In the last months, I got the infamous “it’s by design” answer for many bugs/issues/irrational behaviors I posted to Microsoft. For most of them I used the Connect web site, in a couple of cases I opened a formal incident to Microsoft support.
There are a lot of story (in and outside Microsoft) about the “it’s by design” excuse and most of them are myths and urban legends. Unfortunately, today I received a notification about a bug closure with the “by design” comment that has the consequence to invalidate Microsoft documentation (ok, a small part of…).
The bug is related to SQL Server. One customer wrote me about a strange issue of the ODBC international date constant syntax {d ‘yyyy-mm-dd’}. I never used that, since I prefer the yyyymmdd syntax, but Microsoft effectively suggests using this in the “Writing International Transact-SQL Statements” of SQL Server 2005 Books Online.
As a consultant, I was a little bit shamed because I never used it and I wasn’t aware of the issues raised by changing the language settings (you know, this syntax should be used just because it’s language neutral…). I double checked the whole thing (I always assume it’s my fault before suspecting it’s a product bug…) and then I posted this bug on the Connect web site. For the lazy of you, this is the repro code.
1: USE tempdb 2: GO 3: IF NOT EXISTS (SELECT * FROM sysobjects where name = 'ProblemDate') BEGIN CREATE TABLE [dbo].[ProblemDate]( 4: [DateA] [datetime] NOT NULL , 5: [DateB] [datetime] NOT NULL 6: ) 7: END 8: GO 9: IF NOT EXISTS (SELECT * FROM ProblemDate) BEGIN INSERT INTO [ProblemDate] ([DateA],[DateB]) 10: VALUES ({ d '2004-09-15'} ,{ d '2004-03-30'}) END 11: GO 12: SET language english 13: go 14: -- The select run correctly 15: SELECT CASE WHEN ProblemDate.DateA > {d '2006-11-21'} THEN 'y' ELSE 'x' END 16: FROM ProblemDate 17: WHERE ProblemDate.DateB={d '2004-03-30'} 18: GO 19: SET language italian 20: GO
21:
-- The same select, got an error
22: SELECT CASE WHEN ProblemDate.DateA > {d '2006-11-21'} THEN 'y' ELSE 'x' END
23: FROM ProblemDate
24: WHERE ProblemDate.DateB={d '2004-03-30'}
25: GO
If you were able to say that line 22 will generate a date conversion error before running the code, I’d be ready to offer you a pizza everywhere you are in the world.
Now, it seems that I need to prepare a delivery of pizzas to Redmond, since the bug has been closed as “By Design”. Unfortunately, there are no comments to explain such a decision.
I can make several hypotheses:
- The bug has been fixed in a future release and someone pressed the wrong button closing the bug. That’s the optimistic one.
- The bug has been considered not a bug because I need to pay some pizzas to someone.
- In that case, I will claim the pizzas from the documentation team, which has misguided those few people that RTFM :-)
- The bug has been closed by someone that read one comment to the bug that pointed out a similar issue on the ‘yyyy-mm-dd’ syntax – but it is not a good explanation of the behavior that differs from documentation of the product.
I don’t know. However, the issue I described is not the real problem; it’s just an example to illustrate what happens on the Connect web site. In this case, the answer “by design” has been posted 3 month after the bug submission. Sometime I haven’t seen an answer for many more months. However, it really depends on the team, there are other guys who typically answer in a few days (or some week in the worse case).
I really don’t like writing this kind of posts, but I know that many people in Microsoft monitor blogs like mine and this is a message in a bottle for them. Guys, the whole Connect site isn’t very useful if you will continue to answer with “by design” / “we don’t have resource now” / “it’s not on our plan for the next release (!)”. The last one is my nightmare, because it means that this necessary feature/bug/whatever will be implemented/corrected in a production code that won’t be released until 2011 (assuming that the 3 years gap between SQL Server releases will be maintained).
Posting on the Connect site has a time cost. To me (writing) and to Microsoft (reading and -sometime- answering). I typically post on Connect only after a search in newsgroups and web sites, only when I’m able to describe a repro of the issue. Until today, I submitted 44 comments (bugs and suggestions) for SQL Server 2005 – I’m not the first, but considering an average of 30 minute per post (and I’m not calculating the time to discover the bug of to recognize the need for a feature/change) it means 22 hours of work. Most of my posts are still active. Many don’t have an answer, but I know that Katmai should have improvements covering some of my suggestions. A better update of these submissions would be appreciated…
I think that the Connect web site is a great resource, but it’s not comparable to the kind of support that is offered by some ISV (I use other third-party tools related to SQL Server and .NET programming and they are years-light more responsive). I know, the small size of a company might help in being very efficient in customer support, but I can’t believe that a company like Microsoft is not able to improve the Connect efficiency. In the last 7 days there were 48 new bugs and 31 new suggestions for the whole SQL Server platform (which includes SSIS, SSAS, SSRS, SSNS, SSBS). Are these numbers big? I don’t know. I would say “no, they are not so big for a company like Microsoft”.
Finally… I know, probably there are other priorities. But, in this case, please don’t abuse the “by design” way to fix your bugs.
UPDATE – This bug has been fixed in SQL Server 2008!
Checks whether a condition is met, and returns one value if TRUE, and another value if FALSE.
IF ( <LogicalTest>, <ResultIfTrue> [, <ResultIfFalse>] )
When a column name is given, returns a single-column table of unique values. When a table name is given, returns a table with the same columns and all the rows of the table (including duplicates) with the additional blank row caused by an invalid relationship if present.
VALUES ( <TableNameOrColumnName> )