<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><item><title>Comment on Progress On Dataphor by Leandro</title><link>/blog/progress-on-dataphor#comment-64</link><description>When was ðis posted?</description><pubDate>2011-09-10T22:54:11</pubDate><guid isPermaLink="false">urn:comment:64</guid></item><item><title>Comment on Cursor you Microsoft SQL Server! by fsvcbchf fsdf</title><link>/blog/cursor-you-microsoft-sql-server#comment-63</link><description>At least one ideal to which a database language should strive is the ability to express complex logic simply, concisely, and above all, expressively. This means that having to invoke imperative statements to solve a particular problem should be a last resort within the language. And I suppose that was the case in the story I am about to relate, but the point is, it shouldn't have been!

The problem at hand is a classic hierarchical query with a twist: the tree structure is expressed in a partially temporalized manner that allows for historical as well as future-dated information. Without being able to get into the details, I'll just say that the query to get the actual information as of a given date requires the use of an aggregate. And this leads me to the first problem I had: bit values cannot be used in aggregates. Because no-one would ever want to take the Max() of a bit value. Right.

 Well it just so happens that I did need to take the Max() of a bit, and I assumed that would just work when I was writing the stored procedure embedded in an XML document produced by a C# class generated by a CodeSmith template, but I digress... The point is, it takes about 20 minutes to generate all the classes that actually write the SQL and then rebuild the database with the newly generated SQL procedures. Only then do I actually get the error that Max() cannot be invoked on a column of type bit. So what's the work around:

Max(case when BitColumn = 0 then 0 else 1 end)

Aarrgghhh... But if there's one thing I've learned about T-SQL, it's that the only thing that is consistent about the language is that it is inconsistent. Moving on to the recursive bit of the problem, now that I'm able to express (albeit with some circumlocution) the necessary core part of the query, I decide to use the fancy new common table expression feature of Microsoft SQL Server 2005 to provide a recursive solution to the hierarchical query problem. Beautiful! Or so I hoped...</description><pubDate>2011-07-29T10:34:56</pubDate><guid isPermaLink="false">urn:comment:63</guid></item></channel></rss>
