> 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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
