Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Reporting v Editing Expand / Collapse
Author
Message
Posted Tuesday, August 29, 2006 1:56 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Wednesday, June 20, 2012 5:02 AM
Points: 530, Visits: 945
Comments posted to this topic are about the content posted at temp
Post #304809
Posted Tuesday, September 12, 2006 7:25 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Tuesday, October 22, 2013 11:18 AM
Points: 676, Visits: 432

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.

 

Cliff




Post #307898
Posted Tuesday, September 12, 2006 7:51 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 11:51 AM
Points: 194, Visits: 570
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.
Post #307906
Posted Tuesday, September 12, 2006 10:26 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, August 30, 2013 1:20 PM
Points: 56, Visits: 137
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!

Jon
Post #307972
Posted Wednesday, September 13, 2006 6:37 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, May 8, 2014 6:02 AM
Points: 146, Visits: 238
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.
Post #308159
Posted Wednesday, September 13, 2006 8:01 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Tuesday, October 22, 2013 11:18 AM
Points: 676, Visits: 432

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.




Post #308199
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse