Many of Microsoft’s development products, when given an SQL query, will try to perform all sorts of analysis and breakdowns on the query — usually in an attempt to visualize what’s going on. When the queries become too complex (as the tend to be), they just can’t be parsed and visualized. Furthermore, when the successful parsing of a query is critical to one of their “wizards”, your report creation process can be brought to a standstill.
Queries that have a few levels of subquery nesting, or that have UNIONs, for example, will sometimes break parsing.
So, if you don’t want your development tools (such as Visual Studio) to get in the way of completing a report wizard, put your SQL query in a stored procedure. This way, your tools won’t be concerned with the nitty gritty details of your query. You can still pass @variables to the query, and you can make changes to the query without stepping into your designer’s .rdlc files.
