Our company used to use Oracle system but recently decided to move to Apprise (7.5), which uses Progress OpenEdge 11.1. I checked 11.1 is kind of old but we have NO control. Apprise installs OpenEdge into 3 machines, I was told 2 are application servers and one is the RDBMS? I looked into the installation, there is no easy way to tell which machine installs database, which one is the application server , most menus like "Database Administration Console" are identical in all 3 servers. I did find 11.1 documentation and read some of them, to me , it's not easy to get started with Progress , I hope some one could enlighten me on some of the basics of progress:
1. where to find ad-hoc SQL query tools? such as "mysql" in Mysql and "sql*plus" in Oracle?
2. Database Administration Console is like Sql*server's Enterprise manager? but it doesn't allow me to create a physical database.
3. I assume ABL to progress is PL/sql to Oracle? PL/sql can run inside RDBMS and Application server Forms services ( can be different version but mostly the same). Does ABL run inside the database? why is Application server required ?
To practice I downloaded OpenEdge 11.6 and installed on windows server (both RDBMS and Studio), but I can't find an easy way to play with data like other database systems ( i.e, like Oracle I'll have sql*plus and it tells me some users like scott/tiger to select sample table right away). Please enlighten me the proper way to get started with Progress and become a progress programmer ( Apprise has all API in .r files) , thank you.
1. Squirrel: squirrel-sql.sourceforge.net/
2. OpenEdge Explorer is the DB Admin Console but most non-Windows database deployments simply use the command line tools. They are quite easy to master. Newer versions of OpenEdge have more and more DB Admin Tools in OE Explorer. 11.1 is REALLY old and probably doesn't have that much.
3. The Progress ABL is Progress' language and is much more than PL/SQL..but the analogy is ok. No code runs "inside" the database other than Java stored procedures. All Progress ABL code is executed by one of the many clients: prowin32.exe for Windows; _progres[.exe] is the character client; _proapsv[.exe] is the AppServer agent.
With 11.6 you should have quite a few tools in OE Explorer for playing around with the database.
Do you want to acquire DBA skills or programmer skills? For programming, Progress offers a one month super-intense boot camp at their offices in Atlanta. The price is essentially free: $1000 IIRC.
If you want to acquire DBA skills, you can take one of the DBA classes at Progress but you may be better off working with a company like ours (White Star Software) as we can train, mentor and support you within the context of your environment. Contact me offline if you want more information.
OE is indeed very different from SQL Server and Oracle. Some of the differences you will learn to like.. some probably not so much.
The core ABL (4GL) is very easy to use and you can do everything that you could do in cursor based PL-SQL or T-SQL. Bulk processing is where you will notice the big differences.
There are also UI elements in the ABL that allow you to write GUI/CHUI screens. Quite a few vendors are starting to use .NET/Java/Web for the UI components though. Writing modern UIs in the ABL is much harder than just using a modern UI tool that can call ABL procedures.
The full on IDE tools (like Developer Studio//Appbuilder) are not required to write ABL code. Some of us just use Notepad ++, VIM or other editors to write the code. Depending on how you think this may or may not be easier for you.
Thinking of the OE appservers as traditional appservers and stored procedures is probably best conceptually. Not exactly the same thing but the use cases are the same. For a smaller install this can complicate things compared to SQL Server but any decent sized SQL application should have a similar tiered approach for security/scaling.
I would certainly take Kevin up on his offer. If they already expose common functions via an API it will make your life much easier. Always better to be supported than not. The less you have to go outside of the box the better, especially when it comes time to upgrade your ERP to the latest version.
WRT: "I feel the whole OE system architecture and deployment are more complex than software like Sql*server"
It is the actually easiest system I know:
1. open ProEnv
2. enter: prodb sean sports
3. enter: prowin32 sean -1
Voila. There's your DB, you're connected to it in single user, you're in the editor to write some sample programs (for example: FOR EACH customer: DISPLAY customer. END.). Press F2 to execute the program.
Doesn't get any less complex than that...
Once you want to do production type stuff, with tons of users connected to the system, spread it all out over multiple machines, and so on it get's more complicated, of course. But, it still is easy enough that one person has a chance to know all about it. Show me another system where this is possible... :)
WRT: "ABL is funky".
Analogy: For somebody who is used to drive a horse and buggy a car is funky! :D
I wish you much joy and fun exploring this new language, DB, and environment! May you look back to this time years from now and think: Shoot! Should have known about that sooner!!! :) (y)
SMAT-Tools - Web-Apps with RollBase simpleness, ABL flexibility and power
I am thinking that the comment about "wrap it into a DLL" may have been referring to the "Proxy Generator".
Yes, "wrap it into a DLL" is indeed referring to "proxy Generator". I quoted from the ERP API doc(myself doesn't know such thing yet). The doc also says "unwrapped DLL" too.
I suppose .r files expose method signatures to ABL coding if I include them? The API doc doesn't mention how to use .r files directly by ABL, I think maybe they(ERP people) assume everyone knows and no need to mention? I have not started yet but I need know the .r files can be used as library for ABL programs too.
.r files are run in the AVM - ABL Virtual Machine. This can happen any of several ways. And ABL client can start Progress and designate a starting program which then calls all other program. Similarly with a batch client. Or, one can be initiated in an AppServer agent, which is an AVM, by a call from any one of a number of client types, including OpenClient where the client process can be Java or .NET.
As noted, both procedural .p files and object-oriented .cls files compile to .r. The .p is either just run (and can call other programs in turn) or it can be called persistently. If persistent, then the calling program can execute public (i.e., not private) internal procedures. There are two forms of persistent. The regular one require you to have a handle to the persistent procedure to reference in calling one of its internal procedure. A superprocedure you can just run the IP and it will find the appropriate persistent procedure up the call stack. There are some complicated ways of layering these, but I would avoid that. For a .r from a .cls, it has methods like most OO languages which are public, private, protected like other languages. For a normal class, you must instantiate it and reference those methods via the instance reference. For static methods, you can just reference the name and the instance will be created on the fly if needed, but that instance will never go away until the session holds, so use with caution.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
*.r files are compiled ABL. They are ABL execution byte-code.
You compile ABL source (.p, .w) files and both create .r files (sometimes called r-code)
An analogy is .java files. Those are source, but compile to Java bytecode in a .class file.
The analogy is not perfect because the ABL runtime can run source (like an interpreter) as well as compiled bytecode.
By convention, you would "RUN file.p" even it a compiled version exists. The RUN statement will first look for file.r and run it. Only if it does not exist will it look for file.p.
I work for Apprise, can I ask you to reach out to your implementation person (and/or log an Apprise Care ticket) and we can jump on a quick call together to figure out how we can help. As everyone mentioned above there are a number of free options available but depending on what you are trying to do , I might suggest different starting points.
Using our existing APIs in a third party programming language is one set of skills
Writing general queries in the ABL is a different set of skills
Constructing a new screen in our tool set is... (you get the idea )
Here is some code so you can see the source in action. Sometimes it can be easier to go from something to the docs and see what is going on:
Some videos here:
And a book on OOP with the ABL here:
www.amduus.com/.../Discussions Of Object Oriented Programming In OpenEdge Distribution.pdf
Scott AugéPresidentAmduus Information Works, Inc.Technical Services for Business and Governmenthttp://www.amduus.com/cms
I don't know why I always feel itchy when I see FINDs and FORs without NO-LOCK or EXCLUSIVE-LOCK. ;)
I don't know why I always feel itchy when I see FINDs and FORs without NO-LOCK or EXCLUSIVE-LOCK. ;)
As long as compiling is automated and compile sessions are started with -NL there is little to worry about. Less noise, more productivity.
Those are two awfully big assumptions. And you know what they say about assumptions...
Not my cup of tea either. Always state your intentions explicitly.
You received this notification because you subscribed to the forum. To unsubscribe from only this thread,
post as spam/abuse.
Architect of the SmartComponent Library and WinKit
Had to find so many hard-to-find bugs over the years that where caused by un-tidy code, relying on defaults, abbreviating stuff and such, I am a stickler for following coding conventions. Each of these bugs caused a rule in these conventions. always specify the lock is just one of them...
On the other hand, these samples are just supposed to give you an idea about the basics. If one would do everything as one would in a real application, the concept that is intended to be shown might get lost in the rest...
I wonder, if it would make sense to have some central spot where such best-practice coding-conventions could be published, and where people could make comments about how they would adjust these conventions. That way, a "newbie" could read a little about these ideas every so often and save her/him-self the bloody noses that inspired the various topics...
The problem with this idea is, of course, that every experienced programmer has her/his own favorite ways of doing things, and such a best-practices collection might quickly turn into a religious war-zone, where the original intent is no longer fulfilled...
@Sean: I'm happy to share my conventions with you, if you like. And I am sure, others would do the same...
Thank you everyone for sharing your deep knowledge and great experience with OpenEdge with me. I had to deal with some problems coming up with current ERP so I haven't studied much on OE. I just came back and downloaded the classroom edition. From a very initial glance, OE acts different than others, such as Application Server is almost a "must have" ( our newly installed ERP has 2 AppServers), the ABL is funky, it acts more like an IDE than just a language. Our current ERP uses Providex, which has its own Advanced Business Logic language which we don't like ( easy to have exception ). Our new ERP vendor coded their software in 2 layers: the database side is ABL, the user interface is VB.NET. While I'm not qualified to say anything about how good(or not so good) about ABL, I feel the whole OE system architecture and deployment are more complex than software like Sql*server. it really feels good that I can get help from knowledgable people like you.