New to Progress RDBMS

I'll let those more qualified than me answer the bulk of your query, but, Progress is not a SQL database. It has some support for SQL queries built in. You get a very limited subset in the procedure editor, but you can configure up an ODBC connection the database to perform SQL queries.

Progress has its own proprietary language for enquiring on the data.

Beign not set oriented as SQL, I found it very powerfull.  That's said in my own opinion,  my very reduced sql expertise date before 1990, as I haven't had need to look to it since I met progress db.

It's a relational database. You said so in your first comment, RDBMS means RELATIONAL database management system.

SQL is a standard and a query language for interacting with the database. Progress OpenEdge DB supports a subset of the standard as many other vendors do. And like any other vendor OE DB implements some proprietary extensions. And like any other vendor OE does not implement the full standard.

So I don't think "SQL database" is a good definition and while I'm no expert here, I definitely don't believe ISAM applies.

Thanks @Kirchner just got confuse because to discussion got stumble from stackoverflow > stackoverflow.com/.../what-is-the-worst-programming-language-you-ever-worked-with. The discussion on Progress 4GL. Someone mentioned about Progress 4GL (or Progress ABL) that it was a programming language with a built-in ISAM database access...

Agree with OctavioOlquin I will party on with progress. Using Procedure Editor is soo cool. Just need to get use to using it and experiencing it, just been using it for like 5 months. So very little experience is where curiosity comes in...

Thanks everyone for sharing your thoughts.

I don't think there is a single comment in that gripe about Progress you link to that is helpful (or valid for that matter). For starters it is based on version 7 which is ancient. A lot has changed since then.

The thing that usually confuses new people is that all Progress OpenEdge data is variable length.  Display format  and storage format are unrelated.

Almost  all data written to Progress OpenEdge databases is written by Progress 4GL code.  (4GL is occasionally referred to as "ABL" in the official documentation.)  4GL programs DO NOT care what the "display format" of the data is when they write it.  As a result it is very common for data fields to be "over stuffed".  That is the display format is 30 characters but the field contains 32, or 40, or 93 or 30,000 characters...

Those of us who are "native" to Progress mostly think that this is one of the database's most wonderful features and we are forever flummoxed that anyone would deliberately use something like SQL that is so pointlessly restrictive.

When you use a random SQL tool to query an OpenEdge database you will often think your data is "messed up" because random SQL tools think that the display format of the data is the same as the storage format.

Depending on the version of Progress you are working with this can be dealt with by running the "dbtool" utility which will update a special "sql width" column to reflect the actual maximum width of fields (plus a bit of padding).  Or there are some relatively new parameters that will automatically adjust these things or quietly truncate the returned data.

It is unfortunate but the person who wrote that very obviously had no idea how Progress really works.

a few comments on the 4GL criticisms made on stackoverflow in 2009:

0) version 7 is more than 20 years old. the post is largely misleading and demonstrates ignorance.

1) true - the 4GL was originally designed for use with character terminals. Windows did not exist then. Later, user interface features for use with Windows were added.

2) recent versions have classes and objects in the 4GL. not that i use them.

3) there has been support for one dimensional arrays since the beginning. better array support would be a good thing but not the highest priority for the type of applications for which the 4GL is used or intended.

4) there is no ISAM. the database is made up of tables, rows, and columns, just like other relational databases. tables can have one or more indexes. on-disk storage layout is quite flexible and can be composed of a single data file or many, depending on requirements.

5) it is true that there are cursors. SQL also uses cursors. the 4GL makes it appear as if all the database data were in the applications address space. you just use it and modify it in the same way as you do program variables. unless you use dynamic queries - in that case the language constructs are a bit different.

6) the compiler sets transaction boundaries if you do not specify them yourself. often they are not what you might want, which is why you can set them yourself.

7) everything can be abbreviated. in retrospect, this was a horrible idea and should be stopped.

8) compiler does NOT assume everything is a database access. that is complete nonsense.

9) IMO, for marketing to be calling the language ABL was a mistake.

10) like most languages it is not perfect and has flaws.

10) lastly, the 4GL was not intended to be a general purpose programming language like C. it was designed to make it easy to write business applications and i believe it still does that fairly well and has done so for 30 years.

regards,

gus

“less is my favorite editor. too bad it can’t actually edit files.”

Chris Lesniewski-Laas

I am very much grateful to everyone for enlightening me. Sorry I am very new to Progress. Confusion and misleading were gone to the wind.....

Thank you again guys.......

I definitely agree with this part from Gus: "not intended to be a general purpose programming language" ... like C, C++, or even C#, Java, which can be jitted all the way down to machine code as well.

ABL is a decent tool to use if your business app is heavily database-centered (ie. if you are adding a record, editing a record or deleting a record in an OpenEdge database).  But if you are doing a lot of web U/I or native U/I development then you may need another Progress offering - like the stuff they distribute from Telerik and Infragistics.

If you wish to compare ABL by the numbers, then you might want to look at something like this: www.tiobe.com/.../ (the TIOBE index).  You will find that ABL is ranked pretty low relative to some of the  "general purpose languages".  I would certainly avoid locking yourself into ABL as your *only* programming language.  I think developers should always learn one or two of the top ten ("general purpose") programming languages as well.

[quote user="gus bjorklund"]

9) IMO, for marketing to be calling the language ABL was a mistake.

[/quote]

Which is a commonly shared opinion. Apart from "Progress who?" we now got "ABL what?" [:)]

Can somebody with enough reputation points copy-paste Gus' response as a reply to that ridiculous post on StackOverflow?

About the idea behind 4GL's Edsger Dijkstra dedicated a lecture in 1978 on the subject called

On the foolishness of "natural language programming".

www.cs.utexas.edu/.../EWD667.html .

I for myself find the original ideas the led to the development of 4 GL's unsound.

You could argue ABL is C framework to facilitate CRUD.  It is not really a programming language.  Creating frameworks to facilitate development is not foolish.  Not using the ABL tool where it is beneficial on the premise that it is not a language is invalid.  No one builds anything with a single technology anymore.

Hmmm, "how do we tell truths that might hurt" www.cs.virginia.edu/.../ewd498.html  :-)

> On Jan 25, 2018, at 9:32 AM, agent_008_nl wrote:

>

> I for myself find the original ideas the led to the development of 4 GL's unsound.

>

>

>

the 4GL was not an attempt at “natural language programming”.

unsound by what measure?

in spite of its flaws, i believe it has been successful and, though it is a minority language, a ton of business application have been built with it and those application creators have made a decent amount of money with it.

could it be better? yes, of course, but i do not think the rationale for its design was unsound in 1981.

(i agree with pretty much everything EWD ever wrote)

  On the definition of a 4GL f.e.: www.techopedia.com/.../fourth-generation-programming-language-4gl . "A fourth generation (programming) language (4GL) is a grouping of programming languages that attempt to get closer than 3GLs to human language, form of thinking and conceptualization. [..]". A common vision on what a 4GL is in my understanding (NLP just goes one step further in that wrong direction). Dijkstra's article has everything to do with the rationale for the design of progress 4GL. An inconvenient truth, I understand. Sorry about that.

  The goal of developers of 4GL's was "to make it possible for people who were not computer scientists or informatics experts to create business applications" (your own words). * This goal is and was already in 1981 (Dijkstra's lecture is from 1978) at odds with providing means to create sound (maintainable / robust etc.) software. You could create code which looks like natural language:

for each customer:
   update customer.name.
end.

Maintenance problems here:
- This code can only work if there is a progress (or oracle?) db connected.
- There should be a display connected 
- The query language is not usable with other db's or other collectiontypes than (db- or temp) tables.
- The query language is not composable .
On the last two points see LINQ as alternative (https://queue.acm.org/detail.cfm?id=1394137)

When you want to web-enable your application you have to disentangle the responsibilities that are  - conveniently, making it easy for the businessman without programming knowledge - entangled in the for each above. Striving for a programming language like this is at odds with providing tools to create maintainable (disentangled) software. To create maintainable software you have to have knowledge how to do it and a language that facilitates that. You cannot go back to progress V1, requirements have changed and will change.