Reporting v Editing

  • Comments posted to this topic are about the content posted at temp

  • This article gives a clear defination of what drove your prior decisions. With regards to the cosmetics (Where to place parameter input and labeling of the view report button), you could always put your own face over top of reporting services utilizing the Report component in VS 2005. Report Manager is just intended to be a simple interface to allow users to deliver reports quickly to end users and in that respect it does it's job well.



  • Jon hits the key points very well in his article.  Reporting Services is kind of the "sleeping beauty" of the SQL Server toolset.  Once awakened, it really dazzles the users that see it.  SSRS has been very well received where I work, having replaced scores of Crystal Enterprise reports.

  • Great thought-provoking article. Nice to think a little outside of the box!

    Actually, I have always thought that there are still only the 4 basic functions, Create, Read, Update and Delete (CRUD). It has always seemed a foreign concept to me that reporting systems were somehow "different" and not a part of standard applications. All standard data-driven applications typically support CRUD, so reporting is just reading data and displaying it.

    At the same time, I also have always thought that reports often fill a gap left by missing application functionality.. and there isn't anything wrong with that, when you consider how much time it takes to build a truly well-designed application that accounts for all the possibilities/changes presented by a dynamic, quickly changing business environment. Reports often let users work with data and are quicker to build than applications that might alleviate their need to work with reports.

    By the way, regarding the article, it struck me as kind of funny that reports are considered to be read only, and somehow, reading is an act that doesn't "change" data. I find it's quite the opposite. Take the old saying from physics - by observing something you "change" it! For example, consider a SQL view - depending on how it is written, it could be used to mislead a viewer as to the true contents of the underlying table, therefore changing the perception of the underlying data. Or, having seen a user view some data and believe that there was some trend or meaning when in fact, what they were viewing was a data quality anomaly - data seems pretty tricky that way!

    I guess you've discovered a way with reports to actually combine some Update into your Read - which I don't see any problem with, since reading itself might be considered a "change".

    Enough rambling from me!


  • I have successfully used RS to do a couple of unusual things:

    a) Kick of an SSIS pckage via a job each time a report is run. The stored procedure loop/sleeps until the job is finished and displays the results.

    b) Allow users to select their favourite product portfolio out of all the products our company sells. (this is because some managers specialise in certain products). This report works by listing selected and unselected products and having a link on each product that calls the report itself with a productID and an action code - Select,Delete,Up,Down,None. (Another implicit parameter is User!UserID)

    I would like to hear if people have managed to use RS for other purposes.

  • I have to disagree with you on your "reading data is a change". The act of reading is simply read. By looking at the data, you do not change it. You may request a business logic change in the application or the report itself, but that is seperate from the report.

    "It has always seemed a foreign concept to me that reporting systems were somehow "different" "

    Reporting Systems, good ones, have a different focus on the data model than transactional systems. You design a report data model to be quick to read from, where a transactional system has to be designed to benefit inserts/updates more than reads IMHO. If your application is not a transactional system, there may be some synergy between the report model and your application data model.

Viewing 6 posts - 1 through 5 (of 5 total)

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