Met Open Edge heeft Progress Software Corporation de Open Edge Reference Architecture (OERA) gelanceerd.

Met OERA legt Progress een duidelijke en consistentie visie neer op software architecturen. De scheiding van User Interface, Business Logic, Data Access en Data Storage staat garant voor ‘Future proof’ applicaties.

Since the beginning of Progress it has been possible to get schema information from the 4GL by accessing tables such as _file and _field. In the beginning this used to be unsupported but later on PSC published the structure of these system files in the documentation and on their web site. Each description, however, contained a warning that accessing this information was not guaranteed to work in another Progress version.

When programming small utilities for a specific task, such an import or conversion utility, I have often faced the dilemma of how to provide feedback to the user.

Everybody who is getting involved in version 9 will sooner or later ask himself or herself the following question: what are good uses for the new publish/subscribe mechanism? There are programmers who tried to replace virtually all run statements with publish statements where others are convinced that pub/sub is unreliable and therefore useless.

One of the most exciting features of version 9 is no doubt the support of dynamic queries, buffers and fields.Progress now enables us to create and execute queries at runtime. No 4GL license is needed. The advantages of this capability are numerous.

Starting with version 6.3F Progress incorporates a powerful feature to support the deployment of object code: the Cyclic Redundancy Check (CRC). Each table in a Progress database has it's own CRC number.

The advantage of the CRC is that the same object code can run against different database tables with identical structures, even when these were created at different times using different methods.

One of the most common CRC questions I receive are about a .r deployment situation where the developers are really surprised that the CRCs in the Production database are different from the Development database.
Usually it is Monday morning, the Production database is huge, it is in a remote location and the developers have just spent the entire weekend converting it. First I explain how this is possible and then I inform the developers about the Three Database System as described in Progressions number 30. Slowly they start to realize this is the way they should have done it. I pause for effect.

Validation in an event-driven environment is not as easy as in a procedural environment. In version 6 most validation issues could be resolved by validate phrases since they would always fire upon leave of a (modified) field as well as on GO of the frame.
This would satisfy most validation needs since there was no way the user could continue with the application without applying a GO to the current frame.

In "Reading dBASE files directly from Progress" I describe the structure of the binary header of dBASE files. Using this information it should not be too difficult to write this header ourselves. However, we need some special 4GL constructs to do the trick. This part is in the makebinary procedure.

In these times of object-oriented 32-bit GUI applications I still regularly receive the request to read dBASE files into a Progress database. It seems that 'the outside world' is still using good old dBASE for all kinds of applications, often those that have been running without any trouble for a number of years.