Thanks for the critique. I have access to virtually all of the procs or basic that creates these client's reports. It always comes down to money with my clients, not pure technology. Thus, Re-directing their existing hold-files puts basic and English on the same playing field.
It's a lot easier to take the existing proven report logic and convert the hold-files than to read through each one at a time to re-generate them. The concept of standards is IMHO water under the bridge. My opinions are influenced by my diverse set of clients with barely the same apps running on more than one. Even RESULTS (circa 1981) has had 24 years to deviate and that's evident with my 3 present RESULTS clients. Factor in the other dozen or so systems and there's no such a thing as a standard. In either case, CSV or standards, I am not afforded the luxury of turning simple requests into 15 month projects. I've got to get in, produce the results in a cost-effective fashion and move to the next issue. BTW, I'm the first one to use English for reports. That's what it's there for. But many clients get tickled when I take 2 or more cumbersome reports and combine them into one report either simultaneous or consecutive. They don't care if it's english, basic or BAL. It makes their job easier. my 2 cents. ----- Original Message ----- From: "Stevenson, Charles" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, April 18, 2005 11:24 AM Subject: RE: [U2] Hold-file to CSV > > From: Mark Johnson > > > > How can Basic be limiting. It has everything English (sic) > > has and so much more. In fact, there are many reports that > > 'turn the corner' and cannot be done in English and must be > > done in Basic. > > If you will stipulate that - generally speaking - the most important > attribute of SOFTWARE QUALITY is MAINTAINABILITY then Retrieve / > UniQuery / MVQuery / even English is - generally speaking - the superior > environment for reporting. > READABILITY and CHANGEABILITY are part of MAINTANABILITY. The query > language, being a higher level than Basic is generally more readable. > The self-contained MODULAR nature of dictionary items lends itself to > allowing reports to be easily changed. The can also be REUSED on other > reports. > > In that sense, basic is much more limiting. > > For example (if I may expand on what I *think* Dave S means), if you > have reports defined in the Query language, it is often very simple to > redirect the output in a new CSV format ( e.g., UD: DELIM keyword, UV: > SAVING EVAL "fld1:char(9):fld2"). That is usually much easier to do > than changing a basic program. And when you're done, you've reused > existing code which needs to be maintained once, rather than duplicating > a basic program whose processing is integrated and not modular. When a > change needs to be made (e.g., selection criteria or add output fields, > you have to change 1 shared phrase or I-descriptor rather than dig > through the guts of 2 basic programs. Often the maintenance programmer > will forget there are 2 programs, change only one and the divergence > begins. > > We've had this discussion before. You can look through the archives and > see that I respectfully disagree with Mark's theory of reporting. If > and when I get to set programming standards, I say all reports should be > written in the Query language, unless you can prove your case for doing > otherwise. > There are also techniques involving I-descriptor subroutines, named > common, phrases, etc. that need to be part of the programming standard. > (The SRS.UV.HEADER subroutine mentioned in a recent thread demonstrates > some good practices.) > One reason for not using the query language is for pretty reports that > go to external clients, where the Query language's output format is too > limiting. > Another admitted weakness is the lack of a tool built into any MV IDE to > easily display or group all the modular components of a report logically > for a programmer to browse through them. > > ------- > > Having said all that, Mark's original question was a good one and the > above tangential discussion does not address it. There are tons of > legacy reports from tons of legacy systems (not just MV!) that need to > be deciphered and reformatted into modern spreadsheets. > > I think Mark's original question was this: > Suppose you do not have access to whatever produces the reports, and all > you have is the output report. What is the best way to extract its data > into a CSV file or spreadsheet? > I believe a number of people suggested products to do just that. This > is not just a U2 or MV question & answer. > > - Chuck Stevenson > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
