Progress vs Microsoft Development Environment.

[tamhas]

Do you know of many new shops (with no experience with Progress) in early development stages that adapted Progress as their main development tool?

Sure, any customer of a Progress AP that bought source code.

 

[tamhas]

What do you find either horrendous or mysterious about it. I haven't heard of people who had any genuine interest having any trouble getting pricing.

 

[tamhas]

Don't forget that Oracle gives a 20% discount for being able to fog a mirror, a 30% discount for having a pulse and 50% for a purchase order.

All of which means that any published price list is pretty meaningless.

 

[FrancoisL]

What do you find either horrendous or mysterious about it.

Let see , Access Agent , Machine based , Client Based .. why does it have to be so complicated ... other software treat a user has a user and also progress has no way to enforce this leaving us to hang ourselves by choosing the bad product or license since all the sales rep don't even understand those or can't explain them properly.

Then we go into the whole User VS connection debate where you have at least 3 KB entry trying to differenciated those two with even some KB entry contradicting other on certain details.

All this info has to be dug up in some obscure KB entries . But even if you understand those , the progress DB .lic file tracks connection and not actual users , so if a progress rep inspect your DB , he himself will see 50 user where they may only be 30 using multiple connections wich is supposed to be legal but isn't properly tracked.

We use other Databases , Dev softwares , OCX and none of them comes to the complexity of progress in regards to it licenses or user management.

 

[tamhas]

Well, I agree that it would be better if PSC gave us better tools for monitoring and controlling licenses and I do wish they would add concurrent user back into the list of options for OE10, but I don't find any of it very confusing and I, for one, think that it is a good thing that they offer us a number of options. The Policy Guide lays things out pretty clearly ... pity they don't post that in a public place.

other software treat a user has a user

So, what is this magic definition of a user that covers all situations?

 

[ron]

Thank you all for contributing to such an interesting topic!

I am sorry I left you all debating by yourselves - but due to a technical glitch ProgressTalk temporarily locked me out and I couldn't post! (Thanks Tom for helping to fix it.)

The licencing costs were mentioned a few times. I agree that it is a little frustrating that Progress details are not "publically" available - where those for Oracle and Microsoft are. But - as Tom pointed-out: " [FONT=&quot]Don't forget that Oracle gives a 20% discount for being able to fog a mirror, a 30% discount for having a pulse and 50% for a purchase order.[/FONT]" I happen to know of one customer where Oracle gave an 85% discount! Which means, as Thomas pointed-out, "... [FONT=&quot]any published price list is pretty meaningless[/FONT]".

Of course I expected a fair amount of "religious" propaganda (and wasn't disappointed). That, too, is interesting. In one way or another it tends to flush-out some valuable points.

Tom says he likes the Progress:

FOR EACH customer:
DISPLAY customer.
END.
​

style of "English-like" syntax ... and so do I! Over a lot of years I have worked with many languages (even a lot of assembler) and find some languages "click" with me - and other don't. Progress 4GL "clicks" - C-ish languages don't. But that doesn't matter to me in the current context. I don't anticipate cutting code - I'll hire others to do that.

I didn't mention (sorry!) that whereas in most countries Progress is a "small" community - that point is very much magnified here in Indonesia. There are some especially good 4GL developers, but only very few. On the other hand there are "vast" numbers of developers trained in development using Microsoft tools. From my experience, however, the considerable majority do not have the kind of experience needed. They tend to be poorly trained to understand indexes properly - or transaction scoping - or locking strategies. If I advertise for "VB.NET developers" it is likely that I will get many hundreds of applications - and then there needs to be a meticulous and lengthy process of discovering exactly what capability each one has. (But that's what I have to do!)

I still have a week or two before I have to make a decision on the development environment.

From what I've received so far ....

1. I feel that a mixed Progress/MS environment is not the right way to go.
2. A MS environment is looking like what may be the decision.

That is not necessarily what I would "like" (!) - but considering all the practicalities involved, I feel that may be the "best" option for me to adopt.

Two points concerning SQL Server that I am wondering about:

• Can I extract statistics from a database that are similar to the statistics available from Progress' VSTs?
• No-where anywhere in SQL Server documentation that I have looked at is there a mention of dumping/reloading a database. I am told it is "unnecessary" - because one can do like a table move which has a similar result. Is that correct?

Ron.

 

[rusguy]

Can I extract statistics from a database that are similar to the statistics available from Progress' VSTs?

It does have similar statistics available both by running sql statements and by accessing the sql management studio.

No-where anywhere in SQL Server documentation that I have looked at is there a mention of dumping/reloading a database.

There is a dump and load data functionality but it isn’t used to rebuild the database. Since the technology is different from Progress, different techniques apply to manage and baby-sit the database. Like with Progress DB, you do need to hire a DBA to set everything up for you with SQL.

 

[tamhas]

<I>I feel that a mixed Progress/MS environment is not the right way to go.</i>

An application designed according to modern OERA principles should have the UI independent from the rest of the system, so there is no reason to write off any UI technology up front. Many people have done .NET clients successfully and are very happy. The downside is that you have two technologies involved, but if you can organize your team and work so there is a UI person who knows .NET and other people don't need to do UI, then this isn't necessarily a complication. Lots of people work this way. You can achieve essentially the same result using the ABL GUI for .NET and write everything in ABL, but of course you still need to learn about the .NET controls in either case. If you deploy this solution with WebClient, you don't have the problem of maintaining installations on each PC. I would also consider WUI with one of the rich client technologies since it is zero install on the client and highly flexible in deployment.

You might want to consider bringing in an architectural consultant to help you make up your mind. This choice should really be made based on a five year plan of where your company is going and how IT can support and enable those changes.

 

[rhi]

I too have about 15 years of progress experience as a DBA, but now am an Oracle DBA. If you are even asking the question, then I think you have your answer. If you have an opportunity to expand your skill set into technologies that WAY more users in the world use, then why not?

Would you go to an MS forum and ask - "Hey guys, I have the opportunity to use .Net or Progress?". Would you go to an Oracle forum and ask, "Should I use Progress or Oracle DB?". Of course not, because you don't question the viability of those companies or their technologies.

The truth is that the old "Progress who" lives on strong. And consider the extremely real possibilty that some company like Oracle could snap up Progress and throw away their database, as was rumored to happen at one point with Oracle buying Progress because of their non-Open edge products (Sonic, data direct, etc.).

If I were put in the position of creating from scratch, I would make damn sure I bought technology that will more likely be here tomorrow, than not.

 

[rhi]

That is not necessarily what I would "like" (!) - but considering all the practicalities involved, I feel that may be the "best" option for me to adopt.

Two points concerning SQL Server that I am wondering about:

• Can I extract statistics from a database that are similar to the statistics available from Progress' VSTs?
• No-where anywhere in SQL Server documentation that I have looked at is there a mention of dumping/reloading a database. I am told it is "unnecessary" - because one can do like a table move which has a similar result. Is that correct?

You are correct about the practicalities - go with that.

Regardin VST's and dump & loads. Yes there are Stats in SQL Server, and that is correct that you don't need to dump & load - if you set it up right. Same as in Oracle. You can basically defrag the database while it is online though should you need to.

I think in time you will feel, as I do, that you can't believe what you had to live with in the relatively generic feature-less world of Progress.

See below.

http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

 

[TomBascom]

In the unlikely event that any such rumor ever did come true it is extremely unlikely that the acquiring company would just throw away the database or the 4gl. Just take a look at PSC's financials -- they are cash cows and even Larry isn't that silly.

Sure, learning new technologies is lots of fun. Sometimes it is even useful. But niches are good too. It takes all sorts to make the world go around and this idea that there is just one true path which is dictated by perceived popularity of some tool other than Progress is ridiculous.

 

[TomBascom]

Interesting link.

OpenEdge doesn't look to be nearly as featureless as you seem to think.

 

[rhi]

Interesting link.

OpenEdge doesn't look to be nearly as featureless as you seem to think.

I think the big red NO box under "referential integrity" might say to some whom are very knowledgable about databases that OE might not even qualify as being able to be called a "true" database.

Didn't think I'd really have to point that out but . . . and don't get me started about triggers being used instead.

 

[TomBascom]

I saw that and I don't care. Never have and never will. As defined it's an implementation detail and no one approach is "right".

Anyhow once words like "true" start getting kicked around there isn't much point in discussing it anymore But it is an interesting link. Thanks!

 

[tamhas]

I've seen that link before. Did you note that it was 10.1C?

There are a lot of properties tallied there which are of questionable interest, at least for someone interested in enterprise-class database tools. It probably should be two different articles since the questions one asks about a small lightweight database are different than the ones one asks about an industrial strength database.

I mean ... support for Atari OS?

And, there is a bias toward SQL access. All of the things where OpenEdge got dinged in that section are places where one easily accomplishes the functionality in ABL, one just can't do it in OE SQL. Possibly an issue for some reporting solutions, but not for general application use of the database.

And, of course, nothing really about performance, ease of use, stability, etc. which are of critical importance. The difference in DBA effort required can be a meaningful difference in TCO.

 

[ron]

Once more I wish to thank everyone who has contributed to this thread. It really has been interesting and a number of issues came up that I was not aware of.

I have decided to go "all Microsoft": VB.NET and SQL Server.

Whilst I accept that it is quite possible to develop .NET client applications and have them access a Progress database, I think that is introducing complexities that I can avoid (and should avoid).

Ron.

 

[tamhas]

When you start to tear your hair out, don't forget that you can always come back to Progress!

 

[ron]

Ha! Ha! ... not too much hair left! I'll have to be doubly careful! :lol:

 

[GregTomkins]

I just wanted to add this. Developing a .NET client that access a Progress database would be a really pointless thing to do, IMO, unless you have a legacy DB issue to deal with.

Developing a .NET client that access a Progress AppServer on the other hand, is not a bad plan at all. Personally, I find the ADO.NET + SQL thing a major hassle, duplication of effort, and source of endless irritation compared to the P4GL 'FOR EACH' way. You kind of dismissed 'FOR EACH' as nice syntax in a previous post. It is WAY more than mere syntax.

Anyhow, good luck with VB.NET

 

[ron]

Greg,

I didn't dismiss "FOR EACH" (and Progress 4GL generally) as being a minor/unimportant issue. I dismissed it because here in Jakarta experienced Progress developers are nearly non-existent. If I opted for the AppServer approach I'd have to wear the overhead of training people from scratch - and that's not such a nice prospect.

Perhaps "ADO.NET + SQL thing [is] a major hassle" - but there are rather a lot of people here who have a lot of experience in dealing with it.

My decision was based partly on technical grounds, but largely on practical issues.

Ron.