[comp.software-eng] need help choosing between INGRESS and PROGRESS

bryan@resource.UUCP (Bryan Beck) (05/09/89)

I am in the process of making a DBMS selection, and I have narrowed my
choice down to INGRESS and PROGRESS.

I have found that both are quality packages and capable of handleing the
job.  The only negative comment I have received is concerning INGRESS's
query/report generation capabilities.

Does any one have experience with both packages or qualified to compare
and contrast the two. Also I haven't heard anything negative about progress,
has any one had any complaints??

Any revelant comments that could help me make my decision would be
greatly appreciated.

					Thanks,
  					Bryan 
-- 
Bryan M. Beck                                       Resource Systems
UUCP: {pyramid|rutgurs}!osu-cis!resource!bryan      Suite 390 2454 Farmers Drive
VOICE: (614) 764-7800                               Columbus, Ohio  43235

pasker@ws2s.rtech.COM (Robert Pasker) (05/11/89)

In article <985@resource.UUCP> bryan@resource.UUCP (Bryan Beck) writes:
>I am in the process of making a DBMS selection, and I have narrowed my
>choice down to INGRESS and PROGRESS.
>I have found that both are quality packages and capable of handleing the
>job.  The only negative comment I have received is concerning INGRESS's
>query/report generation capabilities.
>Does any one have experience with both packages or qualified to compare
>and contrast the two. Also I haven't heard anything negative about progress,
>has any one had any complaints??
>Any revelant comments that could help me make my decision would be
>greatly appreciated.
>					Thanks,
>  					Bryan 
Gee, Bryan, I hear Ingres is a great product and therefore
you would be making a grave error in choosing any other 
database. 

:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) 
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) 
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) 
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) 
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) 
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) 

- bob.

ps: if you would like to talk with some of the Ingres developers
about the report writer, try comp.databases.
****************************************************************************
;Bob Pasker
;pasker@dragon.rtech.com
;Relational Technology (we are not a dating service!)
;1080 Marina Village Parkway
;Alameda, California 94501
;W - 415-748-2434
;H - 415-695-8741

rwb@viusys.UUCP (Rick Butland) (05/11/89)

[ I tried to mail this, but my mailer puked on your address ]

I really don't have any experience with development using either package.
From what I've seen, I like both packages' development tools.

I just wanted to relate to you some problems I encountered with Progress
while benchmarking it.  I think that Progress has some real problems
dealing with a multi-user environment.  Performance, particularly on a
multi-processor machine, was poor.  The primary limitations I found were:

(Disclaimer:  These observations are based on an older release of Progress,
(3?), and may no longer apply.)

o  Single-server architecture.  In a multi-user environment, a database
server is started to service requests to access the database.  This, to me,
is a Bad Thing.  As the number of users began to rise, the server quickly 
became overwhelmed, due to the fact that it takes on the responsibility for
everything, from writing the before-image file, reading/writing the database,
parsing messages, servicing the message queues, managing data buffers, etc.  
As evidence of this, the benchmark I ran took a single user 8 seconds to
complete.  At 64 copies of the same program, with simultaneous starts,
the end-to-end time was around 1 hour 5 minutes.  This was a multi-processor
machine, (a three CPU Arix), however, after a period of time, the only
process eligible to run was the server, leaving the other two CPU's nearly
unused.

o  The handling of data buffers, (which are located in the dataspace of the
server), was poor.  Buffer lookup was obviously linear, rather than hashed,
thus contributing to the degradation problems.  Caveat:  Version 4 of 
Progress was to fix this.

o  Before-image handling - The problem here was that everytime you accessed
the database, a copy of the accessed page was written to the before-image file.
Unfortunately, it was always appended to the end of the file, and would not
reclaim unused space.  The file just continued to grow and grow, and at one
point, with a 100k database, I had a 11 MB before-image file.  The problems
of file system indirection really took a toll.  Caveat: in version 4, the
developers told me that they were going to build in a mechanism that would
rewind this file, when there was no activity on the database, whereas the
version I saw required a shutdown before this would occur.

o  No support for raw devices - They claim some form of raw i/o (on a 
filesystem??), but all that I saw were synchronous writes.

They claim short development times with their 4GL, and I'd believe them,
it really does look pretty good, kinda Dbase-like.  Perhaps FoxBase might
be something to look into?

Anyway, I think it's probably an ok product, and the 4GL is really nice, but
be sure, if you're on a Unix system, with multiple users of the same 
database, that your application will perform adequately.  

I've only seen Ingres demo'd, so I can't speak to that product.

Rick Butland
(rwb@viusys)

Disclaimer: My dog won't let me speak for him, much less my employer.

steve@violet.berkeley.edu (Steve Goldfield) (05/11/89)

I haven't used PROGRESS, but I can confirm the weakness
of Ingres' report writer.

First of all, it is limited to a single retrieve, so if
you need to report information from more than one table
(as you do in any well-designed relational database), you
have to first do a retrieve outside the report into a table
just for the report. (Example: You have names in one
table, addresses in a second, and phone numbers in a third.
You have to combine these into a single table prior to
running a report on that table.)

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.

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.)

These are just the most annoying weaknesses that leap immediately
to mind. Naturally, you could overcome all of them by writing
a report in C. What really gets me going is that all of the above
facilities and more were available in dBASE II on my Kaypro 2.

Steve Goldfield

jas@ernie.Berkeley.EDU (Jim Shankland) (05/12/89)

In article <24295@agate.BERKELEY.EDU> steve@violet.berkeley.edu (Steve Goldfield) writes:
>I haven't used PROGRESS, but I can confirm the weakness
>of Ingres' report writer.
>
>First of all, it is limited to a single retrieve, so if
>you need to report information from more than one table
>(as you do in any well-designed relational database), you
>have to first do a retrieve outside the report into a table
>just for the report. (Example: You have names in one
>table, addresses in a second, and phone numbers in a third.
>You have to combine these into a single table prior to
>running a report on that table.)

Last time I used the RTI INGRES report writer (a while ago!), the
"single retrieve" certainly didn't have to be a single-table query!
Nor was there any restriction on the use of views in the retrieve
query.  I agree that if what you say were true, it would be a very
serious limitation.  Perhaps this is an RTI (commercial) INGRES
vs. University INGRES confusion? (I assumed the original poster
was comparing two commercial DBMS.)

>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.)

Such aggregations probably *should* be done in the query language;
that's what it's there for.  Seems wrong to me to duplicate that
functionality in the report writer.  Of course, then the report writer
needs to support reports containing the results of multiple queries.

Jim Shankland
jas@ernie.berkeley.edu

"Blame it on the lies that killed us, blame it on the truth that ran us down"

robf@squid.rtech.com (Robert Fair) (05/12/89)

>First of all, it is limited to a single retrieve, so if
>you need to report information from more than one table
>(as you do in any well-designed relational database), you
>have to first do a retrieve outside the report into a table
>just for the report. (Example: You have names in one
>table, addresses in a second, and phone numbers in a third.
>You have to combine these into a single table prior to
>running a report on that table.)

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.
>
>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.

>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

steve@violet.berkeley.edu (Steve Goldfield) (05/13/89)

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

elgie@canisius.UUCP (Bill Elgie) (05/13/89)

In article <24295@agate.BERKELEY.EDU>, steve@violet.berkeley.edu (Steve Goldfield) writes:
> I haven't used PROGRESS, but I can confirm the weakness
> of Ingres' report writer.
> 
>   [ list of various weaknesses ]
>
 I'm not a fan of INGRES's report writer ( I have never really found one that
 I did like, actually), but there are actually two of them.

 Steve's comments all do apply to the screen-painting version.  There is also
 a much more powerful one based on a pseudo-language  (the screen-painting
 version actually translates to the pseudo-language and can be dumped and mani-
 pulated).

 greg pavlov (under borrowed account), fstrf, amherst, ny

steve@violet.berkeley.edu (Steve Goldfield) (05/15/89)

In article <2358@canisius.UUCP> elgie@canisius.UUCP (Bill Elgie) writes:
#>In article <24295@agate.BERKELEY.EDU>, steve@violet.berkeley.edu (Steve Goldfield) writes:
#>> I haven't used PROGRESS, but I can confirm the weakness
#>> of Ingres' report writer.
#>> 
#>>   [ list of various weaknesses ]
#>>
#> I'm not a fan of INGRES's report writer ( I have never really found one that
#> I did like, actually), but there are actually two of them.
#>
#> Steve's comments all do apply to the screen-painting version.  There is also
#> a much more powerful one based on a pseudo-language  (the screen-painting
#> version actually translates to the pseudo-language and can be dumped and mani-
#> pulated).
#>
#> greg pavlov (under borrowed account), fstrf, amherst, ny

Not sure what you mean by a "screen-painting" version. I'm
writing these reports in the Report-Writer language and
loading them with sreport. If there is a more powerful
report language, why isn't there a manual to describe it?
My suspicion is that you are talking about screens rather
than about reports.

Steve Goldfield

phelan@dlcdev.UUCP (Bill Phelan) (05/17/89)

In your previous article, you listed your objections to the PROGRESS
version 3.  Currently, we are shipping Version 5, which includes:

        (1) a Multi-threaded, multiserver database engine;  For local
            users, PROGRESS uses shared memory to manage locks and takes
            advantage of multiple processors.

        (2) has new buffer management routines that employ hash algorithms

        (3) supports heterogeneous networks

        (4) resolves the before-image file usage

        (5) supports ANSI Level I SQL and most of Level 2, including support
            from the 4GL.


You really should take a look at the product again.

For less than a hundred bucks, you can get a complete copy of the product
to try on your system.  CALL 1-800-FAST4GL and ask for a Test Drive.

fyl@ssc.UUCP (Phil Hughes) (05/17/89)

In article <24295@agate.BERKELEY.EDU>, steve@violet.berkeley.edu (Steve Goldfield) writes:
> I haven't used PROGRESS, but I can confirm the weakness
> of Ingres' report writer.
> 
> First of all, it is limited to a single retrieve

Yuck.  This is not a problem with Progress.  How can you have a
real relational database if you can't retrieve stuff from multiple tables?

> Second, there are no flags or, more generally, user-controlled
> variables to control flow in the report.

The same language is used with Progress to write screens and reports
(which I think is a real plus.)  It is a full blown programming language
and you can do virtually anything in it.  The only limitation that I don't
like is that there are no passed variables in call lists if you precompile
the called module.  You can, however, pass stuff in global variables
or compile at run time (or even build a new program and then run it all
within a report).

> Third, ...

Not a problem for the same reason as 2 above.

-- 
Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155  (206)FOR-UNIX
    amc-gw!ssc!fyl or uunet!pilchuck!ssc!fyl or attmail!ssc!fyl

monty@delphi.uchicago.edu (Monty Mullig) (05/18/89)

fyl@ssc.UUCP (Phil Hughes) writes:

	In article <24295@agate.BERKELEY.EDU>, steve@violet.berkeley.edu
	(Steve Goldfield) writes:
	> I haven't used PROGRESS, but I can confirm the weakness
	> of Ingres' report writer.
	>
	> First of all, it is limited to a single retrieve

	Yuck.  This is not a problem with Progress.  How can you have a
	real relational database if you can't retrieve stuff from
	multiple tables?

well, now, wait a minute.  sure, ingres is disappointing in a number
of ways, but the idea that you can use only one table in the report
writer just isn't true.  what we have here, i think, is a failure to
communicate.  ingres allows only one SELECT statement in the report
writer, but of course that SELECT statement is a full featured SELECT
and can include joins to other tables.

--monty

steve@violet.berkeley.edu (Steve Goldfield) (05/18/89)

In article <3295@tank.uchicago.edu> monty@delphi.UUCP (Monty Mullig) writes:
#>
#>fyl@ssc.UUCP (Phil Hughes) writes:
#>
#>	In article <24295@agate.BERKELEY.EDU>, steve@violet.berkeley.edu
#>	(Steve Goldfield) writes:
#>	> I haven't used PROGRESS, but I can confirm the weakness
#>	> of Ingres' report writer.
#>	>
#>	> First of all, it is limited to a single retrieve
#>
#>	Yuck.  This is not a problem with Progress.  How can you have a
#>	real relational database if you can't retrieve stuff from
#>	multiple tables?
#>
#>well, now, wait a minute.  sure, ingres is disappointing in a number
#>of ways, but the idea that you can use only one table in the report
#>writer just isn't true.  what we have here, i think, is a failure to
#>communicate.  ingres allows only one SELECT statement in the report
#>writer, but of course that SELECT statement is a full featured SELECT
#>and can include joins to other tables.
#>
#>--monty

You may have missed my earlier response to this point.

1. I am discussing Ingres 5.0 which is all we've got (and that
   will soon be phased out here, too).

2. The Ingres Report-Writer reference manual states quite
clearly, on page 4-8, "Only one .query command is permitted
for a report, and only one data retrieval statement is
permitted within the .query command." So, while that single
retrieval statement may, presumably, join several tables,
it didn't do me any good when I needed to append from two
tables and then join from other tables. This restriction
is a severe one.

Steve Goldfield

monty@delphi.uchicago.edu (Monty Mullig) (05/18/89)

Steve Goldfield writes:

	2. The Ingres Report-Writer reference manual states quite
	clearly, on page 4-8, "Only one .query command is permitted for a
	report, and only one data retrieval statement is permitted within the
	.query command." So, while that single retrieval statement may,
	presumably, join several tables, it didn't do me any good when I
	needed to append from two tables and then join from other tables. This
	restriction is a severe one.

Exactly what i said, one SELECT.  And, you're absolutely right, the
report writer is severely limited.  I end up going straight to ESQL/C
for anything remotely complex, and reserve the report writer for the
trivial reports.  I was only correcting the misunderstanding that the
report writer allows queries on only one table; I certainly wouldn't
try to do anything more than that, like defend the thing as a great
tool, it isn't worth that...

--monty

cspencer@spdcc.COM (Cliff Spencer) (05/19/89)

In article <1932@ssc.UUCP> fyl@ssc.UUCP (Phil Hughes) writes:
>and you can do virtually anything in it.  The only limitation that I don't
>like is that there are no passed variables in call lists if you precompile
>the called module.  You can, however, pass stuff in global variables
>or compile at run time (or even build a new program and then run it all

This is the real pain in the butt about PROGRESS. It should be noted that along 
with the restriction on all arguments to other procedures being passed as 
globals, compiled code size is restricted to < 63K. This can lead to code
that is more contorted than need be. 
							-cliff

allbery@ncoast.ORG (Brandon S. Allbery) (05/25/89)

As quoted from <241@dlcdev.UUCP> by phelan@dlcdev.UUCP (Bill Phelan):
+---------------
| For less than a hundred bucks, you can get a complete copy of the product
| to try on your system.  CALL 1-800-FAST4GL and ask for a Test Drive.
+---------------

Blatant advertizing.  Boo, hiss.

...I was unable to evaluate Progress for our uses because the limit of 4
runs on a Test Drive database is too small.  (25 would be adequate for a
test.  I am _not_ asking for an unlimited-use version.)  The use of
"crippleware" to evaluate a package is more often than not an exercise in
frustration; few such packages have limits that are sufficient to evaluate
the product under a "real" workload.

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery@hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser