newbie to Progress but an "old" programmer, where to start? - Forum - OpenEdge General - Progress Community

newbie to Progress but an "old" programmer, where to start?

 Forum

newbie to Progress but an "old" programmer, where to start?

This question is answered

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.

Sean 

Verified Answer
  • 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.

    Regards,

    Paul Koufalis
    White Star Software

    pk@wss.com
    @oeDBA (https://twitter.com/oeDBA)

    ProTop: The #1 Free OpenEdge DB Monitoring Tool
    http://protop.wss.com
  • 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)

    Thomas Hutegger

    tmh@smat-consulting.com

    SMAT-Tools - Web-Apps with RollBase simpleness, ABL flexibility and power

All Replies
  • 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.

    Thank you

  • Sean,
     
    The Proxy Generator tool takes .r code, looks at the signatures (parameter lists) for the .r itself and for any exposed internal procedures or functions and generates C# code which is compiled down to a DLL.  The resulting DLL can be included (along with two runtime DLL’s) into a Visual Studio project and from there you can instantiate your proxy, connect to the AppServer and execute the different .r programs and their available internal procedures or functions on the AppServer.
     
    Basically it makes .r code into method calls on an object.
     
    Brian

  • .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.

  • Hi Sean,

      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 )

    Thanks

    Kevin

  • 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:

    www.amduus.com/.../

    Some  videos here:

    http://amduus.com/training/

    And a book on OOP with the ABL here:

    www.amduus.com/.../Discussions Of Object Oriented Programming In OpenEdge Distribution.pdf

    Amduus Information Works, Inc.

    Technical Services for Business and Government

    http://www.amduus.com/cms

  • https://github.com/progress/WhyABL

    I don't know why I always feel itchy when I see FINDs and FORs without NO-LOCK or EXCLUSIVE-LOCK.  ;)

  • Marco Mendoza

    https://github.com/progress/WhyABL

    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...

    --
    Tom Bascom
    tom@wss.com

  • Not my cup of tea either. Always state your intentions explicitly.

  • +1
     
    Gesendet von meinem Windows 10 Phone
     
    Von: bronco
    Gesendet: Dienstag, 9. August 2016 22:36
    An: TU.OE.General@community.progress.com
    Betreff: RE: [Technical Users - OE General] newbie to Progress but an "old" programmer, where to start?
     
    Update from Progress Community
    bronco

    Not my cup of tea either. Always state your intentions explicitly.

    View online

     

    You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • 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...

    Thomas Hutegger

    tmh@smat-consulting.com

    SMAT-Tools - Web-Apps with RollBase simpleness, ABL flexibility and power

  • 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.

  • I think complex is the wrong word.  Flexible is the word I would use.  <smile>