I recently submitted a bug to Microsoft Connect concerning the behaviour of the expression language in SSRS, if you’re interested you can read about it here: DateAdd() doesn't throw an error when it has invalid parameters.
I got a swift and detailed reply (for which I am grateful) from a fellow on the SSRS team however the content of it wasn’t exactly music to my ears:
While I do agree it would be desirable to have an error here, the SSRS engine makes use of the VB code engine for functions such as this. So, the call to DateAdd is just a passthrough as far as SSRS is concerned. The majority of the functions available in SSRS are actually just VB ones.
In other words the inequities of SSRS’s expression language are down to the frailties of a 14 year old scripting language that should have been thrown out long ago on the coattails of Crystal Reports. Am I the only SQL Server BI developer that feels a little … oh I don’t know … unloved sometimes by the various BI teams in SQL Server land. Let’s have a look at some of the things that we have to put up with:
- two different expression languages (one for SSIS, one for SSRS), neither of which support comments as far as I am aware, neither of which have any debugging features and neither of which are extensible
- an expression language in SSRS that is based on a dead scripting language and rarely produces meaningful errors
- an expression editor in SSIS for which there isn’t even context-sensitive help let alone intellisense
- an MDX query editor in SSMS that doesn’t have intellisense
- a script task editor in SSIS that shows read-only system variables in the ReadWriteVariables dropdown
- I could go on…
None of these issues are particularly prohibitive on their own but when you add them all up (along with many others) I’ve no doubt that we could all be a heck of a lot more productive were they all solved.
I look around at our cousins in .Net land and I see their fancy WPF code editors, extensible languages, Javascript Intellisense, code navigation shortcuts, mockable code, code style checkers, MEF-compliant IDEs, type-inferencing, 3rd-party code editors, keyboard shortcuts, modern type-safe compilers, code generation templates, meaningful error messages, proper debuggers, runtime watches, collapsable code regions, IDEs with built-in refactoring support, built-in code formatting, code documentation tools, whitespace highlighting, code performance analysis tools, LINQ, fluent this-that-and-the-other etc… and I can’t help but feeling a little hard done by. (Anyone that has used Resharper for .Net will know exactly what I mean.) Am I the only SQL guy that feels like a second class citizen in the Microsoft developer ecosystem?
I must be fair and admit that we have it a lot better than other database platform developers (if you have ever used any of the plethora of Oracle developer tools out there you will know what I mean) but nonetheless it would be nice to see a little bit of love go the way of us lowly SQL bods don’t you think?
OK, rant over. My apologies if you came here hoping for some words of wisdom but I’ve been wanting to get this off my chest for ages; normal service will be resumed forthwith!
@Jamiet
P.S. A valid response to this from the SQL Server team may be “submit your ideas to Connect”. I’d like it to be known that the majority of things I have listed above have already been submitted to Connect in some way shape or form and I would be happy to supply a list if one were required!
I should also apologise to the SSRS team for making an example of them – the submission highlighted above is hardly the most annoying of problems listed here but it just happened to be the one that pushed me over the tipping point to writing this!