• All of this is all well and good until you try to use it like:

    • Use custom authentication so you can use it on a web app across the internet
    • Use the report builder to make simple master/child details
    • MS made a school boy implementation error with Report builder where it doesn't close connections when it's done with them meaning you crash it fairly easily. We used some of our MS partner support time to get a workaround figured out whereby you can extend the max connections from 1 to a maximum of 1024 so you can delay the crash for a while
    • Have report parameters that show a list of options obtained from the database alphabetically ordered

    ...it is such hard work.

    The custom authentication is a massive headache. There are not many resources online about the configuration required. There is no UI whatsoever to do this you have to do it all by hand changing XML files where one wrong character can screw you over.

    MS has depreciated report models in SSRS 2012 so pretty screwed if you are using them once 2008 R2 is dropped from MS support.

    Creating a simple report that shows a master line, several details rows, master line, several details rows which takes 5 minutes in something like MS Access after writing the query is only possible with a sub report that has it's own dataset in SSRS - i.e. a lot more work - at least using report builder - which given the context of a self-surface web app is the only option.

    Think very carefully about your requirements before integrating this into your product. I for one would love to rip it out and not use it - we only used it because we were using SQL Server for the data storage so we already had it - hindsight, sweet hindsight - if only I could have seen the future.