Disadvantages of PROGRESS databases

[nick]

Its quite easy to collect advantages of a Progress Embedded Database system and programming in Progress , but I wonder if there are more disadvantages than just this one I've figured out:

"Progress does not create executables (.exe -file) so it is not possible to create an application and deliver it to customers without Progress-license." -> quite an expensive :blue: joke for realy small bussinesses.

 

[Unregistered]

How about the horrible support in terms of documentation, books etc for developing web apps etc using common technologies, ASP, JSP, PHP, COM etc.

No your just stuck using webspeed that is proprietary to Progress, or paying up to your VAR for training. Thank God were starting to use DB2.

 

[ChrisPaulson]

My rant list: -

Very slow 4gl.

Not 24 by 7 utils for DB.

No online defrag for DB.

Poor SQL engine for 3rd party tools.

A very chatty client-server model that should have been fixed, but they just came up with appserver and thought that was good enough.

Previous to 9.1 the 4gl was weak as a language.

They have gone all internet centric mate, some of us couldn't give a s**T about the internet.

Got no databound OCX for DB, this limits the OCX's you can use.

Progress spent a large amount of time on smart objects - and they are pants.

You have to now admin tricks to get the DB to perform.

The most used widget in the language - the browser is pants, but it's getting better.

If you are with a vendor and it's not the biggest its probably going to be bought up. Look at informix.:dead:


I do like Progress but it could have been so much better.

 

[Unregistered]

How about the one the DEC vendor kids me about.

DEC support: Progress supports write back caching correct...?

Me: Ahh no.

DEC support: Hehe your kidding me right?

Me: nope.

DEC support: Well there goes a big speed advantage right there.

 

[ChrisPaulson]

Not that I want to protect Progress on its performance but don't APW's make up for write back caching?

More extra rant: -

How come r-code size is sooooooooooooo big.

Example: write a noddy program with just a few statements etc with no included code and compile it. The generate r-code is bigger than the flat text. DOW!

In our app nearly all our r-code is about 90 - 150% of the size of the flat text. Someone sort the compiler please. NOW!

 

[nick]

If You make a program with C++ the '.exe' is usually bigger than the original code, so it's quite likely that the '.r'-files tend to be bigger. :awink:

But on the other side of the story :

I 've also worked with ORACLE FORMS and there the binary files (original sources) are bigger than the executable files so why did PROGRESS not follow the good example? Lack of skill?

 

[ChrisPaulson]

C++ exes get bigger than source files because they bind in at link time all there class libraries etc.

The libraries are quite big hence the exe size.

Progress does not do this because all its execution logic is bound into prowin32.exe and dlls which are another overhead over and above the r-code.

I could understand why maybe earlier versions were lazy, but why hasn't it been sorted by now. I think it's because Progress is trying to stick its finger in too many pies. Also as with every other company there development department is probably too small.

 

[nick]

We've just compared a delphi executable and a progress runtime,
the delphi executable has three times the size of the progress-runtime but only half the functions ... still minimum doubling in size with progress runtimes (we even have things that expand up to six times original size )

Every environment has things you don't need, so why complain?
If you don't need web-based, don't use that part.

BTW try comparing speed of a version 8.3 application in progress 9.1 environment to a similar 9.1 application in the same enironment ... to our suprise it seems that version 8.3 programs tend to work faster in the 9.1 environment than 9.1 programs
(application main: 2 buttons, behind them 2 forms one in 8.3 the other in 9.1 ; try and be amazed)