What's New in OpenEdge 12.3

OpenEdge now provides a mechanism for clients to automatically connect to an OpenEdge Replication primary target database, if the connection to the replication source database fails. This mechanism uses the -autoReconnect client session startup parameter, and is available when using a client/server connection.

For more information, see Automatic database reconnection with OpenEdge Replication.

This release enhances the utility that converts replication-enabled OpenEdge 11 databases to OpenEdge 12. New options on the PROUTIL conv1112 command let you back up and restore only the schema area. You can use the enhanced utility to convert replication-enabled databases from OpenEdge Release 11.x to OpenEdge Release 12.3 without requiring a rebase of the target databases.

The replsource option backs up physical changes in the schema area of the Release 11 replication source database and the repltarget option restores the schema area to the Release 12 replication target database.

For details, see Convert replication-enabled databases.

Here is a video that shows how to upgrade replication-enabled databases to OpenEdge 12 without a rebase:

You can now use popular port scanning software with OpenEdge Replication without interruptions during database transitions or database log files filled with invalid network messages. By shielding transitions from port scanners or malicious attacks, this enhancement improves the robustness of OpenEdge Replication.

Before-image (BI) files track OLTP changes critical for database functionality. In this release, enhancements let the OpenEdge database detect long-running idle transactions and prevent resource issues due to abnormal before-image file growth. This enhancement saves space and reduces performance issues due to bottlenecks in the BI file system. You can use the -biscantime startup parameter to control how long scans of BI clusters continue.

For more information see Before-image scan time (-biscantime).

The new PROUTIL TABLEREORG qualifier lets you reorganize fragmented record data while the associated table remains accessible to OLTP operations. The new process replaces lengthy dump and load operations, index rebuilds of associated indexes, and replication target rebase. Eligible record data must all be located within the same Type II storage area. Partitioned and multi-tenant tables are supported.

For details, see PROUTIL TABLEREORG qualifier.

In this release, you can change the following startup parameters for secondary login brokers while the database is running:

• Maximum Clients per Server (-Ma)
• Maximum Dynamic Server (-maxport)
• Minimum Clients per Server (-Mi)
• Minimum Dynamic Server (-minport)
• Message Buffer Size (-Mm)
• Maximum Servers per Broker (-Mpb)
• Pending Connection Time (-PendConnTime)

See Change database parameters while the database is running.

An application can now run existing r-code without recompiling if a new database field is added or modified provided the change does not change the OpenEdge data type of the number of extents being reference by the -r code.

For more information, see Relaxed CRC validation rule for precompiled r-code.

From this release onwards, changes to the OpenEdge control codes can be made quickly. You can also add control codes for 12.x report to recorded (R2R) bit products in an existing version of OpenEdge. These products include:

• OpenEdge CDC for Enterprise
• OpenEdge CDC for Workgroup
• OpenEdge Pro2 CDC for Workgroup
• OpenEdge Pro2 CDC for Enterprise
• OpenEdge Multi-Tenant Tables
• OpenEdge TDE
• OpenEdge Table Partitioning

For more information see, Update existing product licenses.

Updates to deployed ABL applications with changes that depend on new schema elements do not require a restart of their ABL virtual machine (AVM) clients and agents to be able to execute the new code.

Here is a video that shows some of the enhancements made to ABL in OpenEdge 12.2 and 12.3:

In OpenEdge 12.3, the following language enhancements are available.

New VAR statement

The VAR statement is a new ABL statement that allows developers to define program variables more concisely, in a manner similar to more modern programming languages. The VAR statement is a shorthand notation for the DEFINE VARIABLE statement. With VAR, you always get NO-UNDO behavior, multiple variables can be defined in a single statement, bracket notation is used for defining arrays, and the equal sign (=) is used to assign initial values.

The following code shows some basic examples of the VAR statement:

/* Four character variables */
VAR CHAR s1, s2, s3, s4.
										
/* Date variable with an initial value */
VAR DATE d1 = 1/1/2020.
										
/* Object variable */
VAR mypackage.subdir.myclass myobj1.
										
/* Determinate array of size 3 */
VAR INT[3] a1 = [100, 200, 300].
										
/* Indeterminate array */
VAR INT[] a2.

For more information, see Learn about the VAR statement or VAR statement.

The new VAR statement does not allow abbreviated keywords when specifying data types; data types must be fully spelled out. To allow for a more concise syntax with VAR, CHAR and INT are now considered full keywords. CHAR is a synonym for CHARACTER, and INT is a synonym for INTEGER. The new synonyms, CHAR and INT, can be used in all ABL statements. The use of CHAR and INT now satisfies the require-full-keywords compiler option.

For more information about the require-full-keywords compiler option, see the COMPILE statement.

New compound assignment operators

ABL introduces compound assignment operators (+=, -=, *=, /=) for performing an operation and assigning a value, using a shorthand notation. Supported operations include addition (numeric and date-based) and concatenation, subtraction (numeric and date-based), multiplication, and division.

For more information, see Compound assignment operators.

Runtime resizing of indeterminate arrays

Previously, if an indeterminate array variable was defined with initial values and you tried to reset the size, a compiler error occurred. Now, you can resize indeterminate arrays at run time even if they are defined with initial values. The following example code illustrates the change:

// Define an indeterminate array with initial values
VAR CHARACTER[] myArray = ["a","b","c"]. 
											
MESSAGE "myArray has" EXTENT(myArray) "elements" 
  VIEW-AS ALERT-BOX.  // myArray has 3 elements
											
EXTENT(myArray) = 10.  // can now reset the size (compiler error previously)
											
MESSAGE "myArray has" EXTENT(myArray) "elements" 
  VIEW-AS ALERT-BOX.  // myArray has 10 elements

This feature applies to variable defined using both the VAR and DEFINE VARIABLE statements.

For more information, see Work with one-dimensional arrays.

Register methods as event handlers for RUN calls

Developers can now register ABL object-oriented class methods as event handlers for ABL RUN asynchronous calls.

Before this release, only procedures could be used as event handlers for the ABL RUN ... ASYNC statement. With this feature, developers can use procedures or methods as event handlers. Public methods in classes are supported as callback handlers. As a part of this feature, the RUN statement is extended to support two new keywords, EVENT-HANDLER and EVENT-HANDLER-CONTEXT. These new keywords allow developers to specify either a procedure or a method as a callback handler.

For more information, see the the following:

• RUN statement
• Event procedures or methods
• EVENT-HANDLER attribute
• EVENT-HANDLER-OBJECT attribute

Register methods as event handlers for server socket objects

Developers can now register ABL class methods as event handlers for the server socket CONNECT event. Before this release, only procedures could be used as event handlers for the server socket CONNECT event. With this feature, public methods are supported as callback handlers for server socket objects, allowing complete encapsulation of the server socket functionality into object-oriented ABL.

For more information, see the following:

• SET-CALLBACK( ) method
• CONNECT event
• Implementing an ABL socket server
• Examples using ABL sockets

Enhanced CONNECTED () method for ABL clients

An enhanced server object handle CONNECTED() method for ABL clients connecting to PAS for OpenEdge instances using the APSV transport is now available. Before OpenEdge 12.3, the method would return a logical value indicating whether the server handle was currently connected, but did not indicate whether there was a valid server session for the ABL client to connect to.

The server object handle CONNECTED() client method was updated to determine if the server also supports the enhanced server object handle CONNECTED() functionality. If both the client and the server support this functionality, then the ABL client sends an HTTP HEAD request to the server, and the request then:

• Confirms that there is a valid session for the client, and returns true or false.
• Resets the session inactivity timer, so that the request sent after the called server-handle:CONNECTED() does not fail due to inactivity.

The following example code illustrates the updated behavior of the server object handle CONNECTED() method:

DEF VAR appHandle AS HANDLE.
DEF VAR ret       AS LOGICAL.
DEF VAR isConnected AS LOGICAL.

CREATE SERVER AppHandle.
ret = AppHandle:CONNECT("-URL http://localhost:8810/apsv -sessionModel Session-managed").

IF (ret) THEN DO:
	isConnected = AppHandle:CONNECTED().
	MESSAGE "connected: " isConnected VIEW-AS ALERT-BOX.
	IF (isConnected) THEN DO:
		// Server object has a valid session for ABL client.
	ELSE:
		// Server object does not have a valid session for ABL client.
END.
QUIT.

For more information about the CONNECTED() method, see CONNECTED() method.

New isConnected() method

OpenEdge 12.3 offers the new isConnected() method for instantiated Progress.Open4GL.Proxy.OpenAppObject instances for Java and .NET Open Clients, which is a logical value that indicates whether there is a valid session on the PAS for OpenEdge server for the requesting client.

Connection connection = new Connection ("http://localhost:8810/apsv", "", "", "");
connection.setSessionModel( Connection.SM_SESSION_MANAGED );

OpenAppObject appobj = new OpenAppObject (connection, ""); 

if (appobj.isConnected()) { 
     System.out.println("connected: true");
     // The session on the PAS for OpenEdge server is valid. 
	// write code to run a procedure with this OpenAppObject.
} else {
     System.out.println("connected: false"); 
}

For more information, see Return the validity of the server session on an OpenAppObject.

The following example code illustrates the new isConnected() method in .NET:

Connection connection = new Connection ("http://localhost:8810/apsv", "", "", "");
connection.setSessionModel( Connection.SM_SESSION_MANAGED );

OpenAppObject appobj = new OpenAppObject (connection, ""); 

if (appobj.isConnected()) { 
     Console.WriteLine("connected: true");
     // The session on the PAS for OpenEdge server is valid. 
	 // write code to run a procedure with this OpenAppObject.
} else {
     Console.WriteLine("connected: false"); 
}

For more information, see Return the validity of the server session on an OpenAppObject.

In OpenEdge 12.3, the merge functionality in the SECPROP utility is enhanced with -f parameter.

For more information about the merge functionality, see SECPROP.

In OpenEdge 12.3, the following third-party tools that are bundled with Progress Developer Studio for OpenEdge were updated. For more information about all third-party tools packaged with OpenEdge, see the OpenEdge 12 Platform Compatibility Guide on the Progress Content Portal.

The "OE Ultra Controls .NET" license ships "Infragistics Ultimate UI for Windows Forms". For OpenEdge 12.3, the version was updated to 19.2.20192.381.

Server-side join improves performance by reducing the amount of data transferred across the network and by reducing the computational cost on the client. Server-side join is available in a multi-threaded database server, and is enabled for queries where the tables to be joined are in the same logical database and there are 10 or fewer tables. Server-side join only occurs when using the following ABL constructs:

• FOR statements with NO-LOCK
• Static or dynamic queries with NO-LOCK, except for those that use the INDEXED-REPOSITION option or involve an outer join

Although the query needs to be NO-LOCK for the server-side join to be in effect, you can obtain records with a lock using the GET statement for a static query, or using the GET method (for example, GET-NEXT()) for a dynamic query.

For more information, see Server-side join processing.

The new SyncToSelectedRow property can be used to control whether the query cursor is repositioned to the selected row after fetching data from another row. The default value is true. By setting the value to false, you can speed up operations that do not require repositioning, for certain use cases.

For more information, see SyncToSelectedRow property.

Optimized SQL can now be generated for INDEXED-REPOSITION queries when the index sort order and the result sort order is opposite.

For more information, see Index repositioning.

The new PROUTIL LOBANALYS qualifier returns information for LOB only. Previous OpenEdge releases included LOB information with table record statistics reports. PROUTIL LOBANALYS collects LOB statistics by table or area, where the area can be the specific LOB area for a table, and skips the collection of table or database-wide statistics.

For details, see PROUTIL LOBANALYS qualifier.

Savepoint support was implemented in the Oracle DataServers. The sub-transactions containing changes to BLOB/CLOB fields can now be undone without undoing the entire transaction. This improves user experience with Oracle DataServers.

For more information, see Handling rollback of sub-transactions.

When coding ABL applications for the Microsoft SQL Server DataServer, FOR buffer statements can now be replaced with FOR statements when retrieving a single record.

For more information, see Replacing FOR FIRST for performance.

OpenEdge 12.3 includes a key distribution application that provides remote STS client key management for OpenEdge Authentication Gateway installations. If you configure your Authentication Gateway server to use an STS server key, each remote OpenEdge installation must generate a corresponding STS client key. The STS client key generation must happen on the client system, and requires the client system to have access to the STS server key. With earlier versions of the Authentication Gateway, this was done though a file share on a remote drive, or by manually copying the STS server key to the client machine. This was a manual process that could leave the STS server key on disk.

OpenEdge 12.3 offers an STS client key management service that runs on the Authentication Gateway through the key distribution application. When you install this service on the Authentication Gateway server using the key distribution application (keydist.war), STS client key generation can be done on the client machine by specifying the URL of the Authentication Gateway server and providing the proper credentials. This can be done through the stskeyutil tool or through the STSKey plugin for the OpenEdge AdminServer.

For more information, see the following topics in the OpenEdge Authentication Gateway Guide:

• About STS client key management
• Configure STS client key management using stskeyutil
• Configure STS client key management using the AdminServer STSKey Plugin
• STS client key management logging

The OpenEdge installation program optionally allows the specification of an OpenEdge Authentication Gateway server and password that will be used to generate a valid client key on the system being provisioned. This option is available for any products that support authentication through the Authentication Gateway.

For more information, see Select your OpenEdge installation choices.

OpenEdge security domains are modeled on a security domain pattern where servers, applications, and databases all trust a common security token that is issued to an authenticated user account that is recognized as a valid user of the domain. Having a fundamental understanding of what OpenEdge security domains are, how they work, and how to configure them, is essential for using them effectively within your OpenEdge application, especially in production environments.

A new document is available on the Progress Content Portal in this release of OpenEdge that explains essential concepts, and also includes a description of how they work in real time to control access.

For more information, see Introduction to OpenEdge security domains.

Currently, the protrace.pid file only contains a stack trace of the SQL process that terminated abnormally on some platforms, making it difficult to quickly identify the specific SQL statement responsible for the crash.

As with all other platforms, a Protrace file will capture diagnostic information such as a SQL query that results in a crash apart from a stack trace, even on Windows.

The -SQLEnableCoreGeneration parameter can be used to generate a core dump when the OpenEdge SQL server crashes.

For more information, see Database server performance parameters.

To stay competitive, your applications need to run as close to 24/7 as possible. In some cases, you can only have downtime limited to 4 hours. This can make upgrading or migrating your OpenEdge database difficult, even with proper planning. With Pro2 version 6.2, you can migrate your OpenEdge database with minimal downtime. In this video, we show you how you can migrate with Pro2.

In previous versions of Pro2, the CDC replication process converted CDC records to Pro2 replqueue records. This procedure increased the total time of the replication.

In Pro2 6.2, CDC replication records are consumed directly by Pro2, bypassing the need for the records to be converted to replqueue records.

The direct replication of CDC works on all Pro2 target database types: Microsoft SQL Server, Oracle Database, and OpenEdge. This enhancement also functions on both network topologies, LAN and WAN.

For more information, see Use CDC with Pro2.

In previous releases of Pro2, bulk-load process used row-by-row transactional commits on target replication database.

In Pro2 6.2, the bulk-load process is optimized to directly generate native SQL INSERT statements and wrap multiple inserts into a single target transaction. This enhancement has improved the efficiency of the loading process. For table loads that run for days or weeks, this overall improvement can be dramatic.

Because the new bulk-load method is a Pro2-produced methodology, this new feature operates identically in both Oracle Database and Microsoft SQL Server environments, allowing Pro2 to provide wide transaction support in Microsoft SQL Server environments.

For more information, see Bulk load with Pro2.