Why Is Progress Still Here?

[BCM]

Our company has licensed a financial application written in Progress 4GL and having a Progress database. We are using Progress 9.1D. Like most U.S. firms our desktop computers run Microsoft Windows and MS Office. To make everyday reporting easier we copy tables from the Progress database to MS SQL Server via DTS. Sometimes the import fails because the data coming from Progress exceeds the data length specified in the Progress database schema.

I have worked with several relational and hierarchial database systems. None would allow storing 60 characters in a column declared as 50 characters. Why does Progress allow this? Please don't suggest an upside to this. It's just poor administration by the database engine.

After seven years of working with Progress I still see the same problem areas: severe difficulty making successful connections with non-Progress systems, non-standard use of the 'dash' character within names, triggers that execute outside the database, and GUI that looks forced.

Surely the reason for Progress could not be licensing; you could get a free copy of Oracle for Linux. I don't understand why the software authors who have developed Progress applications have not ported those apps to mainstream languages and databases.

Tip of the day: The other relational database engines do not require manually locking/unlocking records in code. In this area Progress reminds me of dBase III.

Just my two cents.

 

[jongpau]

Hi,

First of all; as I have said before, please forgive any missing spacesin this post (there seems to be a problem with this forum and FireFoxbrowsers)

To start with the last, your tip of the day... there is no need tomanually unlock records, this happens automatically when thetransaction ends. There is a way to allow Progress to sort out yourlocks for you and that is the automatic lock upgrade which I would notprefer to use or recommend. IMHO, as a programmer you should know whatyou are going to do with a record within a certain code block (anyway,that's what I think - you and others may disagree).

The fact that Progress allows you to exceed the length of the dataasspecified in the database... well, if you would read your Progressdocumentation you would see that the formats as specified in the datadictionary are DISPLAY formats and definately not defining the allowedsize of the data in the db. The maximum size of a field is onlyrestricted by the data type and the maximum records size in yourdatabase. The display format can easily be changed, either in thedictionary or in your programs. I think this makes Progress way moreflexible than all those other db systems that either deny the data tobe stored or just chop it off when it is too long (depends on yourpoint of view of course).

I have to agree with the fact that it is not as easy (or fast) as itcould be to connect to a Progress database from within non Progresssystems.

What is non standard use of the "dash" within names? I have never beenunable to use the dash in field and table names. Even with an odbcconnection this works fine for me. But, if it IS such a problem foryou, then may i suggest you simply don't use this feature?

Does the GUI look forced? Maybe you can elaborate on that one a little?I know that I can create very advanced GUI applications using Progress(and perhaps throw in a couple of standard M$ ActiveX controls).

Licensing: yes, the prices are sometimes over the top, but I suspectProgress is more interested in the bigger fish in the pond and not thatinterested anymore in the smaller applications and customers. But, thatsaid, I cannot prove that.

Move to another mainstream language and db... I think the main reasonfor that would be the cost involved with such an excercise. Sofar,applications that have been developed (and god forbid are stillrunning) in for instance Progress version 5 can still be relativelyeasily be converted to version 9. However, redeveloping an entireapplication in a new language and db will cost way more (costs can runinto many millions of $$$ for larger apps). You would have to retrainyour programmers, redesign your entire app, program it, test it, debugit, document it and then also convince your existing customer base thatthey have to go through a similar excercise when they want to upgrade.And on top of that the customers would also have to convert all theircustomisations to that new application (maybe if they do somedevelopment themselves they would have to retrain their own programmersetc), + test and implement the new app. But, I know that some partiesare trying (or have tried) to do something like this... Question is,will the existing customer base accept it and reinvest in that newapplication?

Anyway, that was my 2 cents worth. I am sure this could potentially turn into an interesting discussion ---> by the way, if anything in this post "sounds" a little harshthen please know that I did not mean to bash, I was just happilytapping away on my keyboard

 

[BCM]

"if you would read your Progressdocumentation you would see that the formats as specified in the datadictionary are DISPLAY formats and definately not defining the allowedsize of the data in the db. The maximum size of a field is onlyrestricted by the data type and the maximum records size in yourdatabase."

All I can say is apparently Progress software developers have not kept pace with the rest of the world with regard to best practices in database management. For the last 10 years database engines have become centralized points of control for data integrity. To achieve a similar level of control in Progress requires much more code executed external to the database. In fact, Progress is not capable of the complete control that is available with Oracle, SQL Server, Sybase, etc. With those database engines, regardless of the method used to access the database - formal front end written in any programming language, ad hoc reporting, ODBC, Excel, etc. - the database engine will ensure that data size, precision, referential integrity, and other rules are followed or the transaction will be denied.

Also, you speak of retraining programmers. In the U.S. it's difficult to find anyone who has even heard of Progress, but everyone has heard of Microsoft, Oracle and IBM. In the U.S. Visual Basic programmers are readily available. In my opinion the retraining is to learn Progress.

Regarding record locking/unlocking... Just use SQL and the database engine will take care of the locks...and you will have less retraining because SQL is generic and Progress is the oddball.

Frankly, I'm beginning to wonder if this is a U.S. versus Europe thing.

 

[John Nebi]

All I can say is apparently Progress software developers have not kept pace with the rest of the world with regard to best practices in database management. For the last 10 years database engines have become centralized points of control for data integrity. To achieve a similar level of control in Progress requires much more code executed external to the database. In fact, Progress is not capable of the complete control that is available with Oracle, SQL Server, Sybase, etc. With those database engines, regardless of the method used to access the database - formal front end written in any programming language, ad hoc reporting, ODBC, Excel, etc. - the database engine will ensure that data size, precision, referential integrity, and other rules are followed or the transaction will be denied.

1) No database engine can ensure referential integrity without code. In this, the databases you mention are no different from Progress.
2) Progress stores data in VARIABLE LENGTH format. The format in the DD is DISPLAY format, not PHYSICAL size. You don't have to WORRY about physical size - Progress takes care of it for you. That is a strength, not a weakness. I personally would have it no other way.

 

[BCM]

John, have you worked with another database like Oracle, SQL Server, Sybase, DB2, etc.? Yes, there is code to manage referential integrity, but the code is stored within the database and executed by the database engine. Have you heard of database constraints? Many of us enjoy the advantages of centralized control in which a well setup database manages itself - except for physical storage growth. It is impossible to have a Progress database manage itself without relying on Progress 4GL code that resides outside the database. A programmer might enjoy the decentralized philosophy of Progress, but the IT manager will hate it.

 

[John Nebi]

You are of course, referring to stored procedures. The Progress SQL 92 engine supports Java stored procedures. You are correct in your observation that the 4GL engine does not, and although you did not state it, it is also not possible to "mix" the 2 engines in the same application. There is really nothing particularly special or unique about stored procedures other than the fact that the code is actually stored in the database - with whatever advantages that affords. The Progress 4GL supports Appserver procedures that run server side, just as stored procedures do, so all of the advantages of being able to run code on the server side are there. True, one cannot store appserver code in the database - but whether one can or cannot do that has absolutely nothing whatsover to do with referential integrity. Yes, I have coded in SQL Transact, and it is a very primitive language, designed to perform the the most basic of tasks. Compared to the Progress 4gl running on the Appserver, the SQL Transact language is laughable.
Oracle's PL-SQL is much more robust - but, in any event, I fail to see that this is anything other than a religious argument.

 

[John Nebi]

An afterthought: The Progress 4gl and the various "SQL" based development environments offer different solutions to the same problems. They have gone down different paths. You may like or dislike one or the other, but it's really a matter of preference, not a matter of one environment being more advanced than or superior to the other. Surely the world is large enough to support different approaches to application development! I personally have found that the SQL development environments, in order to conform to SQL standards, are contorted and artificial - the solutions were created before people really knew what the problems were.

 

[BCM]

Actually, it's more than storing the code in the database. The database engine executes the code. That is the point. I appreciate distributed (parallel) execution for the front-end, but where control is needed centralized execution is ideal (as long as performance does not suffer).

The arguments I see here seem biased toward the application. I make no criticism of Progress 4GL. As a database engine Progress is a joke. Have you ever heard of anyone selecting Progress for the back-end while developing the application in a language other than Progress?

 

[BCM]

Let's try this analogy...

Imagine someone decides to create a passenger vehicle that drives on the roads with other passenger vehicles. This new vehicle uses tires and gasoline available only from the maker of the vehicle or a close partner (like Merant). This new vehicle requires technicians that are highly familiar with the vehicle's systems because those systems are very different from the systems used by all other vehicle makers. Further, few technicians have even heard of the vehicle. As the owner of one of these new vehicles you cannot obtain simple replacement parts at the nearby auto parts store, nor will the nearby garage service the vehicle. So you sit on the side of the road watching the rest of the world drive by because their vehicles have sufficiently enough in common to justify after-market support.

 

[John Nebi]

Your "database engine" is just a fancy term for database server side execution. Of course Progress has a database "engine". All databases have to have an "engine". They wouldn't function without one. Code that updates the database is code that updates the database. Progress uses the "virtual machine concept, much like Java or .net, where compiled intermediate code is interpreted by the _progres executable. It's nice that that the code can be stored in the database. Maybe in the future Progress will provide that for the 4gl, but I don't hear anyone screaming for it. If you want to drive on the same highway, learn Java and use the Progress SQL 92 engine.

 

[bendaluz2]

I'm not going to bother defending Progress as you've obviously made up your mind on it. Can't see why you've bothered to come on here and slag it off though, better to use your time and utilise one of these "superior" developement platforms and port some Progress applications to a more "mainstream" language. You have obviously spotted a gap in the market where thousands of end users are using antiquated systems built on shoddy technology. I'm sure you could make a mint bringing all of these companies in the 21st century. Good luck

 

[lord_icon]

Psc

Wrong place to come to SLAGG of the Progress database. The Progress 4GL / Database rules. It is soo effective, and does not fall over like Bills shoddy attempts. The 4GL language is realy effective and the DB is arguably better than Oracles attempts. The whole package combined makes Progress the way forward.

 

[John Nebi]

Whew! The cavalry shows up just in time.

 

[jongpau]

I'm not going to bother defending Progress as you'veobviously made up your mind on it. Can't see why you've bothered tocome on here and slag it off though, better to use your time andutilise one of these "superior" developement platforms and port someProgress applications to a more "mainstream" language. You haveobviously spotted a gap in the market where thousands of end users areusing antiquated systems built on shoddy technology. I'm sure you couldmake a mint bringing all of these companies in the 21st century. Goodluck

Good on ya bendaluz! You said what I was thinking exactly... And youmay add to that: If he is so unhappy with Progress, why doesn't heeither convince his employer of the fact that he/she has to investhundreds of thousands or millions of $$$ into a new app OR go worksomewhere where they are lovers of Oracle and/or M$ products like thestarter of this thread looks to be? I am sure he will find out that inwith the nice slick mainstream app a modification will take at least 3times as long and cost 5 times the amount of money to get it made...But hey, the database *does* restrict the size of the data that goesinto it wow!!

 

[John Nebi]

Hail to ye Progressers down under! :awink:

 

[jongpau]

...one of which used to be from way up there in Europe... oops... Ishould not have said that because that opens up the possibility of adiscussion on Europe vs the US :awink:

 

[BCM]

I don't have to convince my employer. He already hates it. We'll be rewriting the app using .NET and SQL Server. The database will have well-defined structure, enforced constraints and table relationships, column size/precision rules, internal triggers, etc. The database will enforce those rules regardless of how the user attempts to alter data content - even through a backdoor.

Progress and Java are completely different. Java is a language not a database management system. As a language, Java has similar constructs to many other languages. Java does not prescribe how to address the database.

BTW, I've been developing software for 25 years using Basic, Assembler, Visual Basic, SAS, Focus, Clipper, C, C++, Java, Oracle, SQL Server, Delphi, Progress and other languages. Clearly, Progress and Focus are the odd ducks. Clipper was just a non-gui single user or LAN database - an MS Access precursor.

 

[bendaluz2]

But hey, the database *does* restrict the size of the data that goesinto it wow!!

Pure genius! That will have me laughing for ages, cheers

BCM: I dont think anyone here really cares what you do. You clearly know better than us, good luck to you pal. One thing though....once you've finished your mega app, why dont you tot up how much it cost you to write, then go to the company who wrote your progress app and ask them how much it cost them to write. Then work out how much "better" the new app is and ask yourself if it was worth the difference. Then, come back here and have a conversation with us.

Ta :lips:

 

[bendaluz2]

Noticed another thread you started. From the field names, I think I've used the application you're talking about. Agreed, it is crap

 

[John Nebi]

Noticed another thread you started. From the field names, I think I've used the application you're talking about. Agreed, it is crap

That's really the bottom line. In most cases it has a lot more to do with the developer that the tool.