evan@telly.on.ca (Evan Leibovitch) (04/10/90)
I am considering Progress for a number of database applications. Before taking the full plunge, I am interested in hearing from those of you who have reached its limits, or have come across things it cannot do. Please reply by mail or posting depending on whether you think your answer may be of general interest. Thank you. -- Old fart: Someone who still thinks | Evan Leibovitch, Sound Software that Rafael, Donitelli, Leonardo and | Located in beautiful Brampton, Ontario Michaelangelo are names of painters. | evan@telly.on.ca/uunet!attcan!telly!evan
neal@mnopltd.UUCP (04/11/90)
->I am considering Progress for a number of database applications. Before
->taking the full plunge, I am interested in hearing from those of you who
->have reached its limits, or have come across things it cannot do.
1. No blobs. (Binary Large objects)
2. X windows support is not quite fully there yet.
Haven't found much else in 5 years.... But you have to indicate what you
are comparing it to. 3GL... 4GL... Business Basic...?
Unfortunately, like the elephant that was tied to a post as a baby and now
does not ATTEMPT as an adult to simply rip the post up, I fear that some
of its limitiations we have subliminally accepted and hence cannot recall.
------------------------------------------------------------------------------
Neal Rhodes MNOP Ltd (404)- 972-5430
President Lilburn (atlanta) GA 30247 Fax: 978-4741
uunet!emory!jdyx!mnopltd!neal Or uunet!gatech!stiatl!mnopltd!neal
------------------------------------------------------------------------------dlucy@tropez.UUCP (Doug Lucy) (04/12/90)
In article <26214C8D.42DD@telly.on.ca>, evan@telly.on.ca writes: > I am considering Progress for a number of database applications. Before > taking the full plunge, I am interested in hearing from those of you who > have reached its limits, or have come across things it cannot do. Progress ports very well to all 32 gaskillion machines it runs on, but the VMS version is a real problem (little doc on how to set permissions) The HLC (Host Language Call) facility to jumnp to external routines (for example, C) is very difficult and still does not allow direct database access. The speed of the compiled Progress code is still really slow (due to it's use of stack-machine-like interpretation) If you are developing applications for customers, i.e. they are using Runtime Progress and you are using Development, there is a serious restriction on the compilation/dictionary change routine. Once you've given the client a database and the code you've compiled for the database, you cannot make a change to the data dictionary without recompiling all the code, dumping the client's database, and loading the old data into a database that is "time-stamped" at the same time as your new compiled code. Progress tokenizes references to the data structure in compiled code with the actual location of the records in the database. If you change the data dictionary AT ALL Progress assumes the token id could be different and disallows you from using compiled code and databases that COULD be out of sync. This is a real pain. Even taking all this and more into account, Progress is okay. I prefer a REAL programming language where I get to tell the computer how to make the screen lokk as opposed to an application development system where the computer decides how the screen will look and you must tell it what you DON'T want, BUT I still like Progress. Any questions, plesae drop me email. -- "It's such a fine line between stupid..." | Doug Lucy 703.820.3922 "...and stupid." | DC Pro, Falls Church, VA "Yeah, stupid." | uunet!tropez!dlucy
neal@mnopltd.UUCP (04/13/90)
->In article <26214C8D.42DD@telly.on.ca>, evan@telly.on.ca writes:
->> I am considering Progress for a number of database applications. Before
->> taking the full plunge, I am interested in hearing from those of you who
->> have reached its limits, or have come across things it cannot do.
[ Agreeable stuff deleted ]
->
->The speed of the compiled Progress code is still really slow (due to
->it's use of stack-machine-like interpretation)
[ Don't quite agree; slower than what? Most dbms systems spend their time
in the btree getting records; computational speed just ain't that important.
I agree I would not try to calculate PI with Progress ]
->
->If you are developing applications for customers, i.e. they are using
->Runtime Progress and you are using Development, there is a serious
->restriction on the compilation/dictionary change routine. Once you've
->given the client a database and the code you've compiled for the
->database, you cannot make a change to the data dictionary without
->recompiling all the code, dumping the client's database, and loading
->the old data into a database that is "time-stamped" at the same
->time as your new compiled code. Progress tokenizes references to the
As of version 5 this is not quite that bad.
1. The timestamp is on a file basis; so not all programs need be compiled.
2. You can certainly change the dictionary on an existing DB. There is no
need to dump and reload. (but yes this needs full development, or you must
really dink around with the dictionary sources in the toolkit)
3. Since V5 supports encrypted source, you can ship source to clients.
We do this a lot for clients on "lunatic fringe" machines. The run-time will
compile this encrypted stuff.
->This is a real pain.
->
->Even taking all this and more into account, Progress is okay. I
->prefer a REAL programming language where I get to tell the computer
->how to make the screen lokk as opposed to an application
->development system where the computer decides how the screen will
->look and you must tell it what you DON'T want, BUT I still like
->Progress.
I agree. For personal preferences, give me C and a good screen manager. But
for getting bullet proof applications out quick, Progress is champs.
------------------------------------------------------------------------------
Neal Rhodes MNOP Ltd (404)- 972-5430
President Lilburn (atlanta) GA 30247 Fax: 978-4741
uunet!emory!jdyx!mnopltd!neal Or uunet!gatech!stiatl!mnopltd!neal
------------------------------------------------------------------------------peter@orfeo.radig.de (Peter Radig) (04/14/90)
evan@telly.on.ca (Evan Leibovitch) writes: >I am considering Progress for a number of database applications. Before >taking the full plunge, I am interested in hearing from those of you who >have reached its limits, or have come across things it cannot do. One limit I have reached recently is the short user permission lines. On the one hand, you're allowed to specify user list for the specific operations (such as record add, update or delete), but on the other hand the maximum input line for this user lists is approx. 60 characters. In the examples of the Progress documentation there are only user groups mentioned (e.g. accounting, sales etc.), but think of a bank application in which every transaction which updates the database - must record the name of the user who made the initial transaction - must record the name of the user who controlled the transaction and released it (and both users have to be distinct). Here it's not possible to use group users and so Progress has problems to keep more than, say, 10 user names in the data dictionary. (Anyway, you can write your own user checking system, but as long as a user has access to the Progress 4GL she/he may access the database in any fashion.) Peter -- Peter Radig Voice: +49 69 746972 USENET: peter@radig.de or: uunet!unido!radig!peter