Imagine you’re a database administrator tracing query activity on a server. You’d want all the clues you can get to help you figure out what’s going on. One clue is the name of the client program associated with each database session. This name, passed from client to Microsoft SQL Server when a connection is established, can be used by the DBA to differentiate between multiple applications running on a single client and to focus on (or filter out) activity from the same application across multiple clients.
Does your application pass a meaningful program name to the database server?
Since a view is a saved query and queries can specify ordering, adding ORDER BY a view definition might seem a reasonable proposition. Try it and Microsoft SQL Server chokes. Then you learn the trick: include a TOP clause and SQL Server will be a-ok with ordering clauses in views. You want all rows returned so you add “TOP 100 PERCENT” to your definition and SQL Server is happy!
Yet you notice something strange. Sometimes the rows returned aren’t sorted according to the view’s ORDER BY clause. As you ponder this puzzlement, your mind wonders back to the roundabout syntax required to finagle ORDER BY into the view definition. Is something funny going on? But the answer eludes you. Continue reading
I often refactor SQL, cleaning up convoluted statements using language features such as views, common table expressions and nested joins. It’s one thing to rework a gnarly query into something legible; it’s another thing to verify that the rewritten query returns the same data as the original.
The starting point for verification is comparing the result sets returned by the old and new queries. I’ve recently found Microsoft T-SQL’s EXCEPT operator quite handy for this purpose. Continue reading
Complete (full) dates and unknown dates can easily be stored in a database table via a nullable date column. What about storing incomplete (partial) dates—where the month, day and/or year is unknown? How do we record July 10 (unknown year) or June 2012 (unknown day)? Continue reading
The other day, my friend Jonathan (of Camenisch Creative) surprised me by pointing out that SET FMTONLY ON changes the way Microsoft SQL Server processes control-of-flow statements (IF…ELSE…END, GOTO, RETURN, etc.)
When SET FMTONLY is OFF (the default), SQL Server processes control-of-flow statements normally. In the case of an IF statement, SQL Server determines which conditional expression evaluates to true and then executes the code associated with that expression. Turn FMTONLY to ON and SQL Server executes every conditional branch, even those associated with conditions evaluating to false!
Problem: Microsoft SQL Server Reporting Services won’t populate the data set’s field list. Clicking Refresh Fields does nothing—the field list remains empty.
Is something wrong with the query? Is there a database permissions issue? Let’s check. Click the Query Designer button, then the red “!” (execute) icon. The query runs and…a normal result set is returned. Since the query executes correctly, the query and permissions must be fine. So, the blank field list indicates an SSRS bug—correct? Not necessarily. Continue reading
After inserting a date/time parameter with an expression as its default value into a Microsoft SQL Server Reporting Services (SSRS) 2008 R2 report, I noticed that the date/time control would be disabled when I’d preview the report. Strange.
I learned this fact the hard way the other day! A MERGE statement would not update null values in the destination table with the appropriate non-null data from the source table. My AND clause looked something like “Source.Name != Destination.Name”. I thought that setting ANSI_NULLS to OFF would cause this clause to catch differences when one of the values was null.
Nope! Continue reading