By Design

  • Comments posted to this topic are about the item By Design

  • Good post, good work, and nice use of It depends."

    My approach is to stay "in the box" as much as possible and when I venture from "the box," document as much as possible.

    :{>

    Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics

  • Good post, I agree with the use of it depends and that is by design. As for the use of an SSRS report to modify data, I disagree that this is a bad thing. I have done this before and am in the process of deploying a report that allows the business to set targets through parameters captured on a report. There are good reasons why developers particularly in the BI space would do this. Off the top of my head:

    1. Some data used in reporting is not part of the business application. The most common being how data is grouped and data such as targets. No development resources are likely to be allocated so reporting is easier.
    2. Seeing as no developers are likely to be made available to create an app, the next best solution is MS Excel. This data is captured by the business and a job runs to import the data. There is a risk here as is always the case when using Excel to capture data. I am not going to go into those risks except to say you are reliant on how accurate the user is.
    3. Since the data does not exist, the BI developer can refuse to include it in the report. He will say that he cannot use an Excel spreadsheet to maintain data. The business resorts to exporting data from the reports and creating their own reports in MS Excel that include the missing data. This is one of the reasons that despite great advances in BI tools MS Excel is still the most popular BI tool.

    I think it is all very well to point out the security risk with using a report to update data but it would be better to understand why the report developers have resorted to this solution and even better to give advice on a setup that will protect the client from security issues.

  • Heh... I rank the term "By Design" and, especially, the term "Operates as Designed" right up there with other "lameties" (to coin a phrase and is similar to the well intentioned but still annoying "lame ties" that get hung around our necks on Father's day đŸ˜‰ )  such as "We've always done it that way" and "We've never done it that way before". 

    As for the "Quirky Update", people use such things because they have a need and don't want to wait a day for a supported method to work.  On that note, let's think about it... MS Access has had running totals for a very long time.  Why did MS not think it important enough to incorporate in SQL Server for over 2 decades?  Both are Microsoft products so they can't actually use the "We've never done it that way before" lamety as an excuse.  Instead, they use the "By Design" excuse.

    Now, if we could just get them to fix PIVOT and a couple dozen other things so they work as well as they do in Access.  And what the hell "By Design" process where they thinking of when they "designed" the new splitter function in 2016?  And then there are things like the relatively new FORMAT function.  I can't believe that they actually did any performance testing there.  "By Design", it's comparatively and horribly slow.

    Don't get me wrong.  I love SQL Server but, "By Design", it's not all that it could be or should be.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Um, no. Do it right the first time.

  • I agree that the "fix and inform/advise" solution was the most professional. They probably needed an immediate fix so couldn't wait. The fallout if they fail to take your advice is on them. Just like the benefits would be if they did the work.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • While there are, as stated, obvious risks to updating certain types of data via reports, I think it's highly unlikely that this ability would be removed.  That would then mean that SSRS would no longer be an option in areas where access to data must be logged - and when, for example, the report / sp logs the date, time and user name with parameters to an audit table.

    I'm a DBA.
    I'm not paid to solve problems. I'm paid to prevent them.

  • GeorgeCopeland - Sunday, April 9, 2017 7:49 PM

    Um, no. Do it right the first time.

    That raises the question of 'what is right' though.  If there is a senior user breathing down your neck, with even more senior users breathing down theirs, right is sometimes quick and dirty.  If there is a formal request put through proper channels and you have all the time in the world then there is no immediate reason to use unsupported features or workarounds.  If it becomes apparent that what is requested cannot be done through standard methods then perhaps an unconventional approach is appropriate.  However if that is the case then the user needs to be consulted.  It may be that when they discover that what they've asked for means additional delays, cost and complexity they would rather do without.


    On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
    —Charles Babbage, Passages from the Life of a Philosopher

    How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply