Why Is Progress Still Here?
- Thread starter BCM
- Start date
Good Luck BCM with your .NET and SQL server implementation.
I am actually working on SQL server and .NET since last year. I really appreciate Progress more as a database engine.
At least the deployment from development environment to production is a breeze. All you need to do is an incremental .df file and apply it to production database. Not like the "advance" SQL server, so far, we haven't find out any easy way to copy sql server schema change and new/modified store procedures to production without manually compare them and change production database one by one, especially schema!!. And the "advance" MS store procedure has so much "control" that you couldn't even setup a QA section like progress propath without "manually" backing up all your old store procedures first (thinking about you have to fish through hundreds of store procedures to find those modified ones, and it doesn't show you the modify date!!). I know there are some software companies out there sell some tools to get the schema difference between 2 MS SQL database. But if it's that advance, it should come within the package, isn't it? Since this should be the basic tool for large development environment. IMO, MS SQL is really just designed for one man shop!!
Long Live Progress!!
I am actually working on SQL server and .NET since last year. I really appreciate Progress more as a database engine.
At least the deployment from development environment to production is a breeze. All you need to do is an incremental .df file and apply it to production database. Not like the "advance" SQL server, so far, we haven't find out any easy way to copy sql server schema change and new/modified store procedures to production without manually compare them and change production database one by one, especially schema!!. And the "advance" MS store procedure has so much "control" that you couldn't even setup a QA section like progress propath without "manually" backing up all your old store procedures first (thinking about you have to fish through hundreds of store procedures to find those modified ones, and it doesn't show you the modify date!!). I know there are some software companies out there sell some tools to get the schema difference between 2 MS SQL database. But if it's that advance, it should come within the package, isn't it? Since this should be the basic tool for large development environment. IMO, MS SQL is really just designed for one man shop!!
Long Live Progress!!
You guys just don't appreciate centralized control. Usually programmers do not appreciate centralized control. However, database administrators and system administrators, and the managers who fund the effort do appreciate centralized control.
You can do anything you want. And ask yourself... why are so many systems professionals unaware that Progress exists? Because it lacks critical mass in implementations. Why? Because it's weird and behaves poorly with the majority of U.S. desktops running Windows. The only language that tells you the data will not fit in fill-in frame. Gee, people. We've only been completely GUI for a decade.
The issue of running database triggers in client space is a case in which Progress clearly shows it is phucked. Several years ago I was asked to write a companion application to a large, Progress application. I was instructed to use Visual Basic and to store my data within the Progress database for the large application. The database had hundreds of triggers that were to be by-passed by my application. I discovered that the triggers could be completely by-passed by pointing the application at a directory of empty triggers having the same names as the real triggers. Wouldn't that make the internal auditors happy to know?
Lastly...
Bulley, I do not know you. Most of my Progress experience was gained working with an application named UniFi.
You can do anything you want. And ask yourself... why are so many systems professionals unaware that Progress exists? Because it lacks critical mass in implementations. Why? Because it's weird and behaves poorly with the majority of U.S. desktops running Windows. The only language that tells you the data will not fit in fill-in frame. Gee, people. We've only been completely GUI for a decade.
The issue of running database triggers in client space is a case in which Progress clearly shows it is phucked. Several years ago I was asked to write a companion application to a large, Progress application. I was instructed to use Visual Basic and to store my data within the Progress database for the large application. The database had hundreds of triggers that were to be by-passed by my application. I discovered that the triggers could be completely by-passed by pointing the application at a directory of empty triggers having the same names as the real triggers. Wouldn't that make the internal auditors happy to know?
Lastly...
Bulley, I do not know you. Most of my Progress experience was gained working with an application named UniFi.
On the other hand, its a good job Progress would let you do this or else you wouldnt have been able to write your "VB app where the triggers were to be by-passed by your application". Sounds like your all singing, all dancing centralised control would be a bit restrictive in this situation. In a real situation, your users would not have a development environment on their machines, so would be unable to produce these blank triggers.
jongpau
Member
...and he (BCM) is still around and, unless he changes jobs, will be using his so hated Progress for quite a while longer...
Here's my prediction for the future (if anyone cares to add to this, please do):
*stares into his crystal ball*
- First he quietly realises that converting his application to M$ will take him and an army of M$ programmers several years to complete;
- Then when he is done he will find out that he has 4 to 10 times as much code to manage for the same application/functionality, which will be so much fun when trying to add new functionality, make changes or to debug the thing (will be fun to explain to the people that make the budget);
- Then someone will find out how to hack into his beloved SQL Server database or some new worm will sneak into the system and steal, delete or change all the data in the database (oh, won't it be a heap of fun and try to explain THAT to your auditors). And of course, M$ will fix the problem *after* the fact and throw their hands in the air and innocently say "we are sooo sorry, it is not our fault, we didn't know"
- Then the application will start to throw nice inexplicable error messages (good luck trying to remember those) to web browsers when there is a little misconfiguration in some server, or after someone has applied the next patch level of Windoze or SQL Server. Of course, M$ support will be ever so much fun to get hold of and deal with
- Then M$ will introduce .Net version xyz and, wanting to stay up-to-date, he will have to bend himself (and maybe even another army of programmers) backwards to get his application converted to the latest and greatest ideas of M$ who decide to toss the components used throughout the application out the door and replace them with completely different ones that not only look different, but also work completely different as well (internally)
*sighs and stops staring in his crystal ball*
Like we (bar you) are all saying we all love/like Progress for what it is and what it does, the speed of development it offers, the performance it gets you, the ease of upgrades, etc. If you have your mind set on going M$ and your boss wants to invest his $$ in it, then please do.
If you have good and honest questions, feel free to ask them; if you want to help out others on this forum - yes, please do... that's what this forum is for.
But can you please stop being a serial complainer about Progress, simply because you appear to have no idea how to manage and use it properly (hey, you cannot even remember the error message you say you keep getting). From what I hear, the application you are using is just a heap of *put appropriate word here* from day one, or has been made so by inexperienced people making modifications to it. And, just so you know - and I hope for your sake you do - you can screw up your app just as bad (or worse) when you write it with M$
And that my friends is the last thing I will have to add to this little discussion *places thread on ignore list*
Here's my prediction for the future (if anyone cares to add to this, please do):
*stares into his crystal ball*
- First he quietly realises that converting his application to M$ will take him and an army of M$ programmers several years to complete;
- Then when he is done he will find out that he has 4 to 10 times as much code to manage for the same application/functionality, which will be so much fun when trying to add new functionality, make changes or to debug the thing (will be fun to explain to the people that make the budget);
- Then someone will find out how to hack into his beloved SQL Server database or some new worm will sneak into the system and steal, delete or change all the data in the database (oh, won't it be a heap of fun and try to explain THAT to your auditors). And of course, M$ will fix the problem *after* the fact and throw their hands in the air and innocently say "we are sooo sorry, it is not our fault, we didn't know"
- Then the application will start to throw nice inexplicable error messages (good luck trying to remember those) to web browsers when there is a little misconfiguration in some server, or after someone has applied the next patch level of Windoze or SQL Server. Of course, M$ support will be ever so much fun to get hold of and deal with
- Then M$ will introduce .Net version xyz and, wanting to stay up-to-date, he will have to bend himself (and maybe even another army of programmers) backwards to get his application converted to the latest and greatest ideas of M$ who decide to toss the components used throughout the application out the door and replace them with completely different ones that not only look different, but also work completely different as well (internally)
*sighs and stops staring in his crystal ball*
Like we (bar you) are all saying we all love/like Progress for what it is and what it does, the speed of development it offers, the performance it gets you, the ease of upgrades, etc. If you have your mind set on going M$ and your boss wants to invest his $$ in it, then please do.
If you have good and honest questions, feel free to ask them; if you want to help out others on this forum - yes, please do... that's what this forum is for.
But can you please stop being a serial complainer about Progress, simply because you appear to have no idea how to manage and use it properly (hey, you cannot even remember the error message you say you keep getting). From what I hear, the application you are using is just a heap of *put appropriate word here* from day one, or has been made so by inexperienced people making modifications to it. And, just so you know - and I hope for your sake you do - you can screw up your app just as bad (or worse) when you write it with M$
And that my friends is the last thing I will have to add to this little discussion *places thread on ignore list*
joerocket
New Member
I feel BCM's pain, however...
As someone who was forced into co-existence with Progress, I was in the same camp as BCM a few years ago.
Sure there are not as many bells and whistles as the more "modern" devlopment environments and connections from MS applications could be more robust.
But I have to confess that the stability of our Progress database speaks volumes. I'd rather pull my hair out (what's left) figuring out ways to make applications work with Progress, than explain to Management why our core business data is crashing.
--2cents from an outsider.
As someone who was forced into co-existence with Progress, I was in the same camp as BCM a few years ago.
Sure there are not as many bells and whistles as the more "modern" devlopment environments and connections from MS applications could be more robust.
But I have to confess that the stability of our Progress database speaks volumes. I'd rather pull my hair out (what's left) figuring out ways to make applications work with Progress, than explain to Management why our core business data is crashing.
--2cents from an outsider.
thematrixhasyou
New Member
Yea, PROGRESS is freakin' brilliant
MS Access handles some stuff better than PROGRESS. It's laughable. It took us having a PROGRESS consultant on-site JUST to set up ODBC connections to the PROGRESS database so I can return data inside a web browser!!!!!!!!
I wonder if the vBulletin application that ProgressTalk.com runs on uses PROGRESS as it's backend database (funny). And as far as stability goes, our Oracle 9i and SQL Server 2000 databases have yet to implode under their own weight. It's funny how I never hear anyone talk about what a piece of garbage Oracle 9i is, or how often it crashes.
You folks need to get a life. Don't get so defensive about this product, it's dogsh*t. And don't knock the people that say it, because it's true. No one I know complains about usability, performance, interoperability and scalability with Oracle and SQL Server. If you want others to stop bitching, build a good product or close up shop.
You know what the worst part is? The lack of answers this site really provides. It's not the poster's fault, though. No one knows what the f*ck is wrong with PROGRESS at any given time because there are SO MANY things wrong with PROGRESS, all the time. Just googling solutions for our ODBC connection issues returned PAGES of hits on the PROGRESS KB. And that's supposed to be a simple problem. Ridiculous.
Good luck betting PROGRESS will surpass Oracle and SQL Server. When PROGRESS eventually becomes obsolete, the world will be a much better place.
MS Access handles some stuff better than PROGRESS. It's laughable. It took us having a PROGRESS consultant on-site JUST to set up ODBC connections to the PROGRESS database so I can return data inside a web browser!!!!!!!!
I wonder if the vBulletin application that ProgressTalk.com runs on uses PROGRESS as it's backend database (funny). And as far as stability goes, our Oracle 9i and SQL Server 2000 databases have yet to implode under their own weight. It's funny how I never hear anyone talk about what a piece of garbage Oracle 9i is, or how often it crashes.
You folks need to get a life. Don't get so defensive about this product, it's dogsh*t. And don't knock the people that say it, because it's true. No one I know complains about usability, performance, interoperability and scalability with Oracle and SQL Server. If you want others to stop bitching, build a good product or close up shop.
You know what the worst part is? The lack of answers this site really provides. It's not the poster's fault, though. No one knows what the f*ck is wrong with PROGRESS at any given time because there are SO MANY things wrong with PROGRESS, all the time. Just googling solutions for our ODBC connection issues returned PAGES of hits on the PROGRESS KB. And that's supposed to be a simple problem. Ridiculous.
Good luck betting PROGRESS will surpass Oracle and SQL Server. When PROGRESS eventually becomes obsolete, the world will be a much better place.
If you work in Progress only then Progress is acceptable. But if you have several applications to integrate then Progress is the "difficult child" of the bunch. Many systems professionals in the U.S. are working with large companies that must integrate applications. These firms will not use a Progress application. In fact, THOUSANDS OF U.S. SYSTEMS PROGESSIONALS HAVE NEVER HEARD OF PROGRESS. There is a reason for this.
Why doesn't SAP use Progress? I guess you could have an 'Enterprise' application in Progress if you are in the dry cleaning, auto parts, or video rental business.
Yes, Progress is notoriously bad for ODBC connections.
Yes, I have used Oracle and SQL Server for large applications without the difficulties that come with Progress. We never had to reboot our Oracle server.
Based on the comments of Progress lovers, Progress is their language of choice, and they are not truly multi-lingual. Most of us in the U.S. have to be multi-lingual to be successful. That's because the front-end, middle tier, and back-end are usually developed with different technologies - vb/.net/c++/asp front-ends, Sql Server/Oracle back-ends, and C++/Java/.net middleware. Progress does not mesh well with other technologies.
Why doesn't SAP use Progress? I guess you could have an 'Enterprise' application in Progress if you are in the dry cleaning, auto parts, or video rental business.
Yes, Progress is notoriously bad for ODBC connections.
Yes, I have used Oracle and SQL Server for large applications without the difficulties that come with Progress. We never had to reboot our Oracle server.
Based on the comments of Progress lovers, Progress is their language of choice, and they are not truly multi-lingual. Most of us in the U.S. have to be multi-lingual to be successful. That's because the front-end, middle tier, and back-end are usually developed with different technologies - vb/.net/c++/asp front-ends, Sql Server/Oracle back-ends, and C++/Java/.net middleware. Progress does not mesh well with other technologies.
thematrixhasyou
New Member
John, if you think I'm the ONLY person in the world that can't get ODBC to PROGRESS to work, you're even more delusional than I thought. It's a known problem and a huge one, and it's infuriating that PROGRESS won't allocate any resources to fix it. Guess what, genius, writing dynamic web applications is somewhat popular these days, and last I looked, that required a DATABASE.
ChrisPaulson
Member
BCM, matrixhasyou
Don't tell us to get a life, feel sorry for us.
Some of us are stuck on Progress because they choose it for their very large app many years ago and they cannot afford to re develop.
Yes Progress is poor, but sometimes with hard work a good app can be made out of it.
Yes Progress is out of date, we are all hoping that Progress spends some of the money it leached out of us to modernise the product.
Please have pitty.
PS doesn't vBullitin work on a free open source DB so neither SQL or Oracle
Don't tell us to get a life, feel sorry for us.
Some of us are stuck on Progress because they choose it for their very large app many years ago and they cannot afford to re develop.
Yes Progress is poor, but sometimes with hard work a good app can be made out of it.
Yes Progress is out of date, we are all hoping that Progress spends some of the money it leached out of us to modernise the product.
Please have pitty.
PS doesn't vBullitin work on a free open source DB so neither SQL or Oracle
Similar threads
- Locked
- Petar Grigorov
- Progress Blog
- Locked
- John Iwuozor
- Progress Blog
- Locked
- Joelle Andrews
- Progress Blog
- Locked
- Vyom Srivastava
- Progress Blog
- Locked
- Alexander Shumarski
- Progress Blog