Progress - 2 steps fwd; 3 steps back.

[BCM]

Well, my friends, I have finally come to understand why I dislike working with applications developed in Progress.

Progress is not good for working in sets or matrices oriented paradigms. Sure, Progress programmers work with sets all the time, but the process is iterative throught the sets. For complex processing the elapsed time can be huge. This means that Progress apps do not scale as well as SQL-based database apps (Oracle, SQL Server, Sybase, etc) because the elapsed time grows enormously as the record count increases.

I am suffering through this realization right now as I attempt to improve processing by joining multiple matrices together for the entire population or records. Though my joining is taking place with SQL-based data downloaded from Progress, the task is made impossible by the data organization designed into the app by the 'genius' programmers.

I realize that you people love Progress. Have you ever done complex database processing on multiple sets with a quality database engine that is capable of eliminating unwanted records, aggregating wanted records and joining to other sets all in one routine that runs in seconds versus running in an hour on Progress? You owe it to yourselves to leave the 'dark side' and experience the 'light'.

 

[Flines]

Hi BCM,

Just a question: Which carpet have you smoked ?

Flines.

 

[BCM]

Flines,
No carpet, I'm high on the real thing: powerful gasoline, a clean windshield, and a shoe shine!

 

[lord_icon]

Heavy

I realize that you people love Progress. Have you ever done complex database processing on multiple sets with a quality database engine that is capable of eliminating unwanted records, aggregating wanted records and joining to other sets all in one routine that runs in seconds versus running in an hour on Progress?
** You owe it to yourselves to leave the 'dark side' and experience the 'light'. ***
That is so heavy!!!!

RE: Complete speculation. WHY do we 'owe it to yourselves'. NOBODY can explain to me where the mighty Progress falls down. Everybody else is trying to catch up with PSC.

 

[BCM]

Ok, Lord Icon, you don't owe it to yourself. Let's explore the word 'ignorant'. That word comes from 'ignore' and means to ignore truth. I progam with Progress and the other stuff. I have never met a single programmer, systems analyst, DBA, or IT manager who is trying to catch-up with Progress technology and/or paradigms.

Thanks for reminding me how futile it is to argue with the ignorant or lead a mule to water.

 

[Casper]

Well, I guess you're the messiah?

I hope you find good tidings on your way. GL and Hf.

Casper

 

[joey.jeremiah]

Mr. BCM,

I really understand how you feel. I do my fair share of lashing out, though it's usually not @ProgressTalk.

I respectively think that most of your frustration so far is due to the shop's lack of expertise, no offense intended.

How about posting a sample and we'll try showing you the most efficient and elegant way to accomplish it.

 

[BCM]

You are a friggin' idiot. You just don't get it.

Given: The computer bus adds processing time when data must flow across the bus. That is why more and more processing is built into the chip.

Same thing with the database. Why read sets of data into the memory of a 4GL (or VB, C, C++, C#, Java, etc.) program and iterate through those sets. That requires cursors, and, as any hardcore database developer knows, cursors are expensive - especially when there are millions of records. It's significantly faster to perform set reduction and joins within the database engine itself, never leaving the database engine for work in a separate program. If you don't understand this than you may know programs but not databases.

I know you people don't see this because you can't with Progress. You're so mesmerized with the ability to setup your little screen master-detail browsers that you miss the big picture. You think you're so special, but I have come in contact with Progress programmers at very few, relatively small companies.

 

[Flines]

Smoke

I agree. You have not smoked a carpet. You have smoked a whole field of purple grass...

 

[joey.jeremiah]

You shouldn't. You should use an AppServer.

The inhert problem with a client/server architecture is the potentially great amount of messaging, not just for queries, the business logic should run on the server-side.

At least one of the problems with a client/server architecture. I think the AppServer in Progress was introduced in v8.


A WebClient/AppServer Enterprise license costs the same as a Network Client license, I think, 110 USD.

In OE10.1A you can run procedures from .NET or Java without proxies besides opening them as a web service. Pass data using the ProDataSet object that maps to ADO.NET, Java SDO's and XML.

 

[joey.jeremiah]

For one I really hope you won't leave the forum. As for Progress do what ever makes you happy ...

One thing that usually comes me down is a chat with Greg Higgins, maybe you should try it

 

[lord_icon]

I am NOT arrogant

RE: I have never met a single programmer, systems analyst, DBA, or IT manager who is trying to catch-up with Progress technology and/or paradigms.

That is soo heavy.
Obviousley you will NOT meet a single programmer, systems analyst, DBA, or IT manager who is trying to catch-up with Progress technology.
They would be users of the technology and NOT actual technology - how can users catch up with technology???
If you are going to contradict other talkers view, with utter nonsense then you DO NOT belong here. Go away and steel something, head the M$ route.

 

[Lee Curzon]

As always BCM, so violent, yet so popular in thread views.


[BCM]

Progress is not good for working in sets or matrices oriented paradigms.

True(ish). But to my knowledge, no other development system is as good for working in row oriented paradigms. So na.


[Joey]

I really understand how you feel. I do my fair share of lashing out, though it's usually not @ProgressTalk.

Yes. You need to stop apologising for that btw. A little bit of emotion can be quite entertaining sometimes, particularly on that other staid forum.
Gus accepted your apology, so I reckon its ok to move on. I wouldn't pay too much attention to the greybeards, apart from their technical advice.


[BCM]

Why read sets of data into the memory of a 4GL (or VB, C, C++, C#, Java, etc.) program and iterate through those sets. That requires cursors, and, as any hardcore database developer knows, cursors are expensive - especially when there are millions of records. It's significantly faster to perform set reduction and joins within the database engine itself, never leaving the database engine for work in a separate program. If you don't understand this than you may know programs but not databases.

I know you people don't see this because you can't with Progress.

That's a valid point, and definitely a problem for someone like me not very familiar with SQL. I can see that when you want to apply the same operation across an entire set, SQL is very useful. Perhaps you could explain how SQL copes with operations where the action needs to be formed according to criteria across the current row, and various related rows. I have never been shown how you perform a complicated IF in a SELECT/UPDATE statement. Seriously, I'd like to know.

Certainly a client-side cursor can be a problem, but that is why Client-Server logic (as Joey states) is now separated via Appserver in any serious application.

I would be generally interested in someone familiar with both Progress 4GL and SQL/other database engines instructing me impartially in the pros and cons of both.


Cheers,

Lee

 

[jdgibson]

RE:

I am suffering through this realization right now as I attempt to improve processing by joining multiple matrices together for the entire population or records. Though my joining is taking place with SQL-based data downloaded from Progress, the task is made impossible by the data organization designed into the app by the 'genius' programmers.

RE:

Same thing with the database. Why read sets of data into the memory of a 4GL (or VB, C, C++, C#, Java, etc.) program and iterate through those sets. That requires cursors, and, as any hardcore database developer knows, cursors are expensive - especially when there are millions of records. It's significantly faster to perform set reduction and joins within the database engine itself, never leaving the database engine for work in a separate program. If you don't understand this than you may know programs but not databases.


Progress does select the records to return to the client on the database engine if it is able to do so. For example


For each customer where customer.customernumber = 123:
end.

will only bring back one customer record to the client if the field customernumber is the first field in an index and there is only one record that has that customer number. It would not bring back all the customer records in the table to select the one you want on the client.

Problems arise when the database is not in third normal form, the indeces are badly designed or the programmer writes his query in such a way that it cannot be resolved on the database engine. Under those circumstances the neccessary records are brought back to the client and processing is done there.

Your problems are not caused by the inadeqecies of progress.

Your first problem is the database has been badly designed. You admit your task is impossible in SQL because of "data organisation". If its impossible to be done on the database engine if the query is written in SQL why on earth would you expect it to be possible on the database engine using progress 4GL.

Your second problem is lack of knowledge and experience of progress.

 

[joey.jeremiah]

Progress breaks queries into single table queries. For example: for each order
no-lock, customer of order no-lock:

For every row in the order query a new customer query is opened.


If there are a hundred thousand orders at 1 millisecond on average for each
round-trip.

A query that takes a couple of seconds on a self-serving client takes a
couple of minutes on a remote client.


It's a very general comparison, but in my experience, on average the diff
between a self-service and remote client is 20x. ymmv

In most cases, the diff is bigger because the appserver runs on a higher-end
machine.


We probably won't get a chance to ask BCM, but I'm guessing the case is,
and one that I've seen in a few v8 style programs.

Is that the program first downloads most of the data to the client and then
most of the query is done localy.

Progress is a tool and that's all it is. You can either use it to create
steaming piles of **** or works of art.