• Sue_H - Thursday, June 22, 2017 10:26 AM

    That function is a cool little thing but it probably should have been written as an inline function. If it's not used or called much, it's not going to kill a server to use what's there. I've used my own and the built in one as well...just to be consistent in inconsistency.

    Sue

    That is a mentality that I am very very slowly getting into.  Where I work, we have a bad habit of storing things like that on a network share and just loading the script up whenever we need to run it.  A lot of times, I find a script that ALMOST has what I want online (usually from this forum), then I tweak it to suit my needs.  The one I posted above started like that, but it had a lot more joins and provided a lot of information I didn't care about so I removed a lot of it and then added a few extra things on my own.
    One REALLY bad habit I have is finding a script online, ensure it has no UPDATE, DELETE, INSERT, or DROP commands, then reading through it multiple times to figure out what it does... and then adding a ",*" to the end of the SELECT to see what other info I can pull that may be useful.
    But it does help me learn.  Most (if not all) of my SQL knowledge has been learned from either PASS Summit, SQL Saturdays, my local PASS chapter, or trial and error.  With trial and error being the biggest one.  My best friend is "ROLLBACK TRANSACTION"... my worst enemy is when I am trying to send a message on service broker and for whatever reason, SQL ignores the "COMMIT TRANSACTION" (think it is an "out of memory" error but for whatever reason does not display it).

    But I really like SSRS.  We have multiple reporting platforms where I work, and for the most part, I like SSRS the best.  They all have different benefits.  One does "live excel" documents which are neat but the system is VERY heavily java based and does get stuck in a garbage collection loop at times.  Another is very good at making reports that are very pretty and drill-down-able in a simple, easy to use interface, but has the problem that the data needs to be imported to its own magic format on a schedule, so you get no real-time data from it.  The only thing that sucks about SSRS is the licensing... I think it is silly that if you install SSRS on a server that doesn't have a licensed SQL instance on it, you need a separate license for it.  SSRS is not all that useful without a SQL database to talk to (from my understanding).

    The above is all just my opinion on what you should do. 
    As with all advice you find on a random internet forum - you shouldn't blindly follow it.  Always test on a test server to see if there is negative side effects before making changes to live!
    I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.