I was not much of a coffee drinker before college. In senior year, after only having coffee when I needed to be up late studying, I purchased this coffee maker for my room. Well, it was actually a Christmas present for my parents, but as it turns out, neither of them are regular drinkers.
One of the features I like is its ability to brew at a preset time. For example, during the week, I wake up to the smell of coffee, brewed automatically at 8:00am. Read more »
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.
