Why Progress?

bmetelits

New Member
Occassionally I work on a large financial application developed in Progress with MS Windows-based clients. I always find myself asking "Why Progress?". I have much experience with Oracle and real sever-based SQL client-server systems. The Progress application I support can be a nightmare in distributed computing because the business rules execute locally on client PC's.

Have I been experiencing an unusual type of Progress application or is this the norm? What characteristics of the application or marketplace justify Progress over Oracle for NT or Linux?

I appreciate your thoughtful responses so I may gain insight into the appropriate application of Progress?

Brian Metelits
 

bmetelits

New Member
No Replies in 17 reads: Chicken-Sh#ts

Hey folks. I'm serious. This is not a Progress-bashing thread. I'm not a one-trick pony. I use many languages to solve real problems. I really want to know when Progress is better suited to the application than other 4GL/SQL solutions. I have no intention of wasting what I know of Progress.

Thank-you brave souls who will reply.

Sincerely,
Brian Metelits
 
U

Unregistered

Guest
I should ask you instead of why Progress, why Oracle? I agree with your comments related to Progress, but for a lot less DB2 or for robust web app env SQL 2000. I would prefer those two over Oracle. Oracle is overpriced, overhyped and too complex to setup for its own good.

Perhaps some shops choose Progress because of its initial cost which is A LOT less than Oracle. Any database is a lot less than Oracle.
 

bmetelits

New Member
Thanks for your reply. From your comments I would conclude that the reason to use Progress is mainly one of cost rather than technology. As I have never had to buy Progress I have no idea what Progress licensing costs. I do know that I can get full-blown Oracle enterprise for Linux for free; also, for NT for free or nominal costs.

My experience has been that there's only one ODBC driver for Progress - therefore limiting use on non-Progress development languages. Also, it appears to me that very little actually runs within the database on the server. The Progress application I have worked with knows to look through a variety of disk folders for code. Any module may be overridden or superceded by having a local copy of the code with the same name. That means that database triggers and other business-specific logic may be replaced by your own code. I wouldn't like this at a bank where I had my money because I would not want a programmer to have the ability to re-direct funds to his/her own offshore account.

With Oracle, DB2, SQL Server, Sybase, etc. you cannot do this because the triggers and modules are stored within the database itself and run on the database server under the umbrella of the relational database server engine. This forces centrally managed logic.

Back to the ODBC issue...without ready availabilty of native drivers one would develop in Progress. Progress does not appear to be object oriented. Just yesterday I had the need to pass an integer array to a called Progress module. However, I couldn't do that, so I had to use a Shared Variable across modules that really did not need to know about that variable.

All in all, I have found no reason - other than cost - why anyone uses this language.

Sincerely,
Brian
 

Chris Kelleher

Administrator
Staff member
Originally posted by bmetelits
All in all, I have found no reason - other than cost - why anyone uses this language.

Actually cost is a major (and obvious) advantage, however there are many others as well. I would suggest reading these threads for some other advantages Progress has over other RDBMSes:

http://forums.progresstalk.com/showthread.php?s=&threadid=9146
http://forums.progresstalk.com/showthread.php?s=&threadid=30030
http://forums.progresstalk.com/showthread.php?s=&threadid=27379
 

bmetelits

New Member
Thanks, Chris. I read thru those threads. It seems many ask what I asked. However, at a gut-level, I sensed an appreciation for the Progress 4GL more than for the database. Actually, the 4GL is the unusual part to me. I have been developing since 1980. I've worked on large IBM mainframes using basic, SAS and Mark IV. After buying an IBM PC in 1983 my first project was to write a full-screen editor that worked like IBM's ISPF. On the PC I've developed in MS-Basic, MS-Assembler, Lattice C, Turbo C, Turbo Pascal, Visual Basic, Delphi, PowerBuilder, and Java. Each of these languages (other than assembler) shares many similarities. But Progress 4GL is different. I'm not saying it's good or bad - just different. When I program with Progress I feel like I'm using some kind of "visual" Cobol....and all these FIND FIRST and IF AVAILABLE statements are reminiscent of traditional Cobol. I came from major oil and gas ("7 sisters"). Their legacy accounting systems were all written in Cobol running on IBM mainframes. These have been replaced with SQL-based systems. I find I like SQL. It's remarkably effective at performing large tasks with single statements - albeit complex/nested statements. Also, other than a few proprietary functons (example: Oracle's DECODE) the SQL is portable. I know that Progress is SQL compatible, but in my experience, SQL is rarely used from within the 4GL. Rather Progress programmers opt for writing may lines of code that must be executed on the client. I'm still looking for the reason for this. Perhaps in a real-time system one would seek to define parallel processing and distributed computing as the union of all client resources. I'm just concerned about losing control of the program logic as it, also, is distributed.

Brian
 

ingie

New Member
Progress Client/Server

Hi Brian,

Although it is true that a lot of progress programmers tend toward writing client side code, this is not a flaw of progress per se, but more a flaw of the programmer. ( isn't it always ? ;) )

If you run an appserver, then there is nothing to stop you placing all business logic at the server end, and having a lightweight client app running the heavy stuff on the appserver.

When a progress app is written as such, then the developer has the added advantage of being able to utilise the same business code running on his appserver from a webspeed application, just as simply as with his progress client application.

Regarding full SQL integration within a n-tier client/server environment, I'd be tempted to write an ORB type thing ( in Java or C++ ) at the server end which responds to requests from external clients and does all the dirty work, so you end up with :

progressDB <---> AppServer <---> 'Business4GL' <---> 'BusinessBroker' <---> ORB <---> any client application via any network connection.



Does that help ?
 

johnnebi

New Member
Brian,

As mentioned, the Appserver is the 4gl way of executing server side code. If you like stored procedures, you can use those as well, but they will not work with the 4gl. As mentioned, you would have to use java/sql. Essentially, you cannot mix the 2 environments.

John
 
Top