Path: utzoo!attcan!uunet!ogicse!emory!stiatl!mnopltd!neal
From: neal@mnopltd.UUCP
Newsgroups: comp.databases
Subject: Re: Anyone have Progress beefs?
Message-ID: <46@mnopltd.UUCP>
Date: 13 Apr 90 15:03:09 GMT
Reply-To: gatech!stiatl!mnopltd!neal
Organization: MNOP Ltd., Atlanta, Ga.
Lines: 52
Distribution:


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