|
I disagree with most of your reply Tom. Letting users import reports into Excel is equivalent to pouring gasoline all over the office and then praying that no one strikes a match. But, again, that's just my opinion. Everyone is free to implement their own policies and standards. Thank God we are in America where this is the case and not some other country where differng opinions lead to beheadings and suicide bombings. -----Original Message----- From: "Tom Jedrzejewicz"<tomjedrz@xxxxxxxxx> Sent: 4/25/06 12:51:07 PM To: "Midrange Systems Technical Discussion"<midrange-l@xxxxxxxxxxxx> Subject: Re: Easiest and most functional wayto convertselectedspoolfilesintoExcel Evergreen Interactive Systems makes an interesting product which does exactly what you are looking for and is very reasonably priced. It is called Report Downloader. http://www.evergreeninteractive.com/ We also use Sequel. On 4/25/06, Luke Dalton <ldalton@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > I'm sorry, I just think this has bad idea written all over it. I don't mean > the comment about SEQUEL. I'm sure SEQUEL is a great product. I mean that to > push a spooled file to Excel is a completely idiotic thing to do. Sometimes, sometimes not .. I think you are over generalizing. > First of all, you are assuming that the report is always accurate so that > when it gets to Excel you will never have to question the data. But what if > the report is not accurate? When it gets to Excel the best you can do is > rearrange the data from the report, but you cannot go back and get the RIGHT > data. Kind of like spraying gold paint over a clod of dirt. (I actually had > a more earthy simile there, but I'll let you figure it out yourself.) Actually, part of the point is that these are reports that are trusted and verified and are currently used in manual fashion. Chances are the output is being keyed into Excel already, so all that is really being requested is automating an existing function. If the report isn't accurate, then it doesn't matter what is done with the data. > Second, you are empowering your users to perform what should be a > programmer's function and you are giving them authority to disseminate > potentially erroneous information. And at the same time, by default, you > have implicitly given them the ability to make the claim, "Well, don't fault > me for the incorrect data. I just used the report that IS gave me." I completely disagree that reporting is a programmer's function, in fact I work pretty hard to get IS out of the report generation business. IS (or the system) provides a basic set of reports that we verify and certify, and we setup several "data marts", denormalized, streamlined files for reporting. Beyond that, the users are responsible for the reports that they create and submit to management. > When in > fact, once the data is in Excel, they can do anything they want with it and > make it say anything they want (or anything they didn't want but got > anyway). This horse is out of the barn and into the next county already. One cannot argue that Excel provides opportunity for data manipulation and dishonest reporting. I imagine it was enabling technology for the craziness at Enron and Tyco. Lots of people have heard horror stories of bad decisions made based on spreadsheets with mistakes in the formulas or macros. And how many of us have gotten requests from users complaining that, because our repots don't match their spreadsheets the reports must be wrong!? Nonetheless, we have to deal with it. At my company, we have a defined set of reports used for producing the books on a monthly basis, and those are the "gospel". Management requires that ad-hoc or special purpose reporting of that data balance back to these verified sources. If someone generates a report in Excel that doesn't balance to the system, management is aware that IS isn't the culprit. Crafty users can get Sequel to lie just as easily as they can get Excel to lie, by adjusting the selection criteria or creating a formula. They can do ODBC downloads, import Query reports into Excel, or copy the source data into .CSV files. For that matter, they can pay a high school kid $10/hour to key it. The solution isn't to hold all of the data behind the data center windows and dole it out as we see fit. -- Tom Jedrzejewicz tomjedrz@xxxxxxxxx -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.