T-SQL missing comma in SELECT does not generate parsing error
I ran in to this “gotcha” the other day while writing a number of views. I omitted a comma on my SELECT statement, and the parser did not return an error, but rather just results that I did not expect. The problem is that SQL Server interprets the missing comma as an implied column name. It is as if there is an unwritten “AS” where the missing comma should go.
Screenshots of the three scenarios:
The correct query returns the desired results: two columns of information
Accidentally leaving off the comma results in only one column (with the wrong data)
Adding in an explicit "AS" gives the same results as omitting the comma
I’ve been working with SQL for years and never had this issue before. I supposed it is because if I make a mistake like this, I usually omit more than one comma, which causes a parsing error.
Sorting via parameters in SQL Server Reporting Services
In SQL Server Reporting Services (SSRS) there are two different methods for a user to sort their reports after they have been generated. Other folks have done a superb job of explaining each method, so I’ll just point you to their sites:
The user can interactively sort on a header textbox by just setting the “interactive sort” properties:
http://weblogs.sqlteam.com/joew/archive/2008/08/02/60666.aspx
You can also sort using standard report parameters:
http://www.databasejournal.com/features/mssql/article.php/10894_3492236
Free alternatives to DNSReport on DNSStuff.com
I used to use the DNSReport from DNSStuff.com, but it seems like they are making it harder to use. I researched some alternatives and I came up with these two that I liked the best:
IntoDNS: http://www.intodns.com/
World Wide Web Domain Tools: http://w3dt.net/tools/dnsreport/
Here’s a more exhaustive list with reviews of free alternatives to DNS Report.
Group by month, year, or anything else using a calculated column in SharePoint
I found an excellent example of how to group by month in a blog recently. It does require using SharePoint Designer, however. An alternative to grouping this way is to create a calculated column and group on that.
The end result looks something like this:
:
Basically, you just create a new calculated column in the list. In this case, I called it “Published Month”, type of “string”, with a value of =TEXT(Published,”yyyy-MM”)
After creating the calculated column, just set the “Grouping” for the list. One caveat is that your calculated column is going to be sorted on as well, so it must be in the proper order. For example, the format string “yyyy-MMM”, which produces “2008-Apr”, sorts alphabetically, instead of in date order.