Home Forums SQL Server 2005 Business Intelligence Import Dynamic File Name with a Date/Time as the file type (YYYYMMDDHRMMSS) RE: Import Dynamic File Name with a Date/Time as the file type (YYYYMMDDHRMMSS)

  • Jeff Moden (6/12/2013)


    opc.three (6/11/2013)


    Jeff Moden (6/11/2013)


    For example, sp_MakeWebTask was very well documented and supported and it went away virtually overnight because Microsoft thought everyone would go ga-ga over SSRS :sick:

    sp_MakeWebTask was likely dropped from the product in part because it sucked, and also because it was accepted that CPU time available on a database server is much better spent managing data and not generating HTML documents. To that end moving development dollars into furthering these capabilities within the Microsoft Data Platform Stack into a system that could be scaled up, out and extended far more easily and cost effectively, namely SSRS. You can generate HTML by doing a bunch of string concatenation in T-SQL and people do, and that handles many basic needs, but certainly not in a structured way with a proper HTML parser or object translation layer.

    Similarly, Microsoft will eventually come to their senses and drop xp_cmdshell, in part for the same reasons mentioned above (especially the first one I mentioned) and provide a replacement tool. Oh wait they already did drop it...have you had a look at SQL on the Azure Platform? And they already have provided a capable and more robust replacement to bridge the OS-to-SQL Server gap, namely PowerShell.

    BWAA-HAAA!!!! It sounds like you never used it before because it certainly didn't suck! And it was a proper HTML "parser" (generator, actually). It allowed both structured and unstructured use which was great for both long term projects and the "gotta-have-it-now" urgencies. It even allowed for style sheets to be used and was incredibly easy to use. It was a nice, tight, little COM object that produced instant results instead of being better at producing little green timing circles on the screen. It was awesome!

    You've also forgotten that a huge number of people have SSRS installed on the same server as their data. There goes the supposed CPU advantage. For those that install SSRS on separate systems, there goes the cost advantage because now they need another license and they have another machine to maintain, virtual or otherwise.

    Oh I've used it. That's how I know it sucks. Talk about a finicky monolith.

    With SSRS, you're right in that a lot of people go the "food court" option and install everything on one server. Great. Start out like that. But later, when you're BI stack is publicized and the accounting department loves you for it, you can move your SSRS operations to a new box. What happens when all your stuff is locked up in T-SQL? Add more hardware I guess, right? Start manually offloading operations to a new database server? It's much harder to "refactor" a database instance than it is to scale out your different services onto hardware that is built specifically for, and can be tuned specifically for, the type of workload it is being asked to do.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato