Xref: utzoo comp.databases:2514 comp.lang.misc:2938 comp.software-eng:1514
Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!agate!violet.berkeley.edu!steve
From: steve@violet.berkeley.edu (Steve Goldfield)
Newsgroups: comp.databases,comp.lang.misc,comp.software-eng
Subject: Re: need help choosing between INGRESS and PROGRESS
Keywords: INGRESS, PROGRESS
Message-ID: <24380@agate.BERKELEY.EDU>
Date: 12 May 89 20:33:46 GMT
References: <985@resource.UUCP> <309@viusys.UUCP> <24295@agate.BERKELEY.EDU> <2894@rtech.rtech.com>
Sender: usenet@agate.BERKELEY.EDU
Distribution: na
Organization: University of California, Berkeley
Lines: 92

In article <2894@rtech.rtech.com> robf@squid.UUCP (Robert Fair) writes:
#>
#>>First of all, it is limited to a single retrieve, so if
#>
#>This  is not really correct - the RETRIEVE/ SELECT is a  full function
#>query, so you can use joins, subqueries, views etc to access more  than
#>one table in the report.  However, I agree that only a single query
#>can be annoying sometimes.

The annoyance was the point. I *always* have to run quel
scripts and generate temporary tables before running the
reportwriter because of this limitation. I quote from
Ingres/Reports: Report-Writer Reference Manual, Release 5.0,
August 1986: "Only one .query command is permitted for a report,
and only one data retrieval statement is permitted within the
.query command." p. 4-8 In order to get what I want into a
report, I typically have to run two appends and two replaces.

#>>Second, there are no flags or, more generally, user-controlled
#>>variables to control flow in the report. (Example: you want
#>>something to happen only on page one, like suppressing a
#>>page number in the footer.) The only thing like a variable
#>>is information read in at run time from a terminal.
#>
#>The report writer has had flow control(IF-THEN-ELSEIF-ELSE-ENDIF) for
#>a long while. Release 6 has real variables, with data types, NULLability
#>attributes etc.

Since Release 6 isn't available here, it doesn't help much. I use
the if then else etc. constructions, but they don't always do the
job. Thus, there is some flow control but not complete flow
control.

#>>Third, you can count or compute other aggregations, but you can
#>>only count everything inside a report. You can't count on a where
#>>condition. (Example: I wanted to report all employees of a
#>>company in our database and count the number of those who
#>>were alumni of this institution. I couldn't do it in the
#>>report. I had to do it in quel.)
#>
#>Wrong. You can count etc over any break in the report, or print
#>cumulative values throughout the report.  Your example, to print
#>the number of alumni in each instituion might be written as:
#>
#>	.FOOT institution
#>		.print "Number of alumni in instituion ", 
#>			institution, " is ", count(alumni)
#>
#>which is pretty easy.
#>>
#>>Steve Goldfield
#>
#>Robert Fair
#>RTI Tech Support

On the last one, either I didn't communicate clearly or you
missed the point. There's only one institution involved. Some
people are alumni and some aren't.

I have a group of employees of a company
in a table which I have already retrieved in a query. Some but
not all of them are alumni. I want to print them all out in
alphabetical order, and I want to count them in total and also
count the subset of those who are alumni.

It is true that I could count them if I sorted on the field
which tells whether they are alumni (though there are three
different values of that field for alumni), but that isn't
the report that I wish to run.

What I had to do was to throw away the nonalumni in my query
and only include the alumni in my report to get a count of
alumni in the report. Unless you can suggest a way I could
have gotten the report I wanted (a not unreasonable one, I
would argue), I continue to maintain that Ingres' report
writer, at least the 5.0 version available to me, is
pretty lame.

So, while you can count over a break, you still have
to count *all* the rows in that break. You can't count or
sum only those which meet a condition as you can in
quel. In some cases, I've gotten around this one, for
sums, by creating separate columns in my report table
in which the rows I want to sum have nonzero values.
In the above case, I could create an alumni column
which is 1 for alumni and 0 for others and sum that
column. My only point is that in a well-designed
report writer I wouldn't have to go to such lengths.
(Incidentally, I wish I'd thought of the above solution
sooner.)

Steve Goldfield