Known 3.5 Issues to Resolve

Note: Ensure that any already identified, existing problems with your applications have been corrected or documented. More problems may appear during the conversion process; deal with each of them in one of these two ways before proceeding. Not correcting or documenting problems as they are identified is likely to waste considerable time during the conversion process.

The most common issues are those related to field properties. Color and transparency issues are hard to detect and quantify comprehensively by manual means, and realistically they cannot be fixed manually, because there are too many occurrences. But they can be corrected simply using an automated tool.

This developer issue is widespread and will need to be corrected in most applications. It typically manifests as frames having areas with the wrong color. Actian provides an automated PropertyChanger utility to assist you in correcting this problem. To request the PropertyChanger tool, contact Actian Support at http://supportservices.actian.com/support-services/support#contacts.

For more information about this issue and its resolution, see Incorrect FP_CLEAR Field Setting and Upgrading Applications with the PropertyChanger Utility.

If you are using your own color definition file for OpenROAD and plan to continue to do so, you may skip this section.

ISSUE: OpenROAD changed the color definitions it uses between version 3.5 and 4.0. These definitions have not changed since.

In applications developed initially in OpenROAD 3.5, CC_PALE_GRAY and CC_LIGHT_GRAY were identical, and many fields were set to one or other indiscriminately.

The same thing happened to CC_SYS_BTNFACE when Microsoft’s definition of their button gray was switched from rgb(192,192,192) in Windows NT to rgb(212,208,200) for Windows XP.

When you convert to the latest release of OpenROAD, the grays will be unacceptably different and will need to be reconciled. In many cases, the other colors will differ from those in the OpenROAD 3.5 application potentially to such an extent that they also will need to be changed.

RESOLUTION: If you decide to reset the non-gray colors, the most effective and low-cost route is to define your own color table (see the following procedure).

We recommend that you reset the grays. Since no adjustment of the color table will deal with the change to CC_SYS_BTNFACE, and the distinction between CC_PALE_GRAY and CC_LIGHT_GRAY in existing applications is a developer issue and not an intentional implementation, we recommend that you use the PropertyChanger tool mentioned previously to correct this (see Incorrect Field Colors). For more information, see Upgrading Applications with the PropertyChanger Utility.

1. Make a copy of the apped.ctb file in your OpenROAD 3.5 installation (\ingres\files\apped.ctb). Name it something like apped_latest.ctb.

3. In a command window on your OpenROAD 5.1 installation (that is, with the II_SYSTEM appropriate to that installation), issue the following command to point the OpenROAD color handler to your new file:

In the unlikely case that they are not, you will need to adjust the settings in the CTB file until the colors are acceptable.

5. Change your deployment specifications to ensure that %II_SYSTEM%\files will contain apped_latest.ctb, and II_COLORTABLE will point to apped_latest.ctb in each upgraded client installation.

See Incorrect Field Colors.

Note: If you are certain that all of your TableFields use OpenROAD’s built-in TableField header or use no TableField header, you may skip this section.

If your application may have some pseudo-headers built within a separate StackField, you will probably need to make corrections.

It is possible that a simple font change will fix this problem in most or all places. Where it does not, you will need to scan the entire runtime application manually for table header alignment discrepancies, and correct them individually.

ISSUE: TableFields in OpenROAD 3.5, although powerful, had limited column header support compared to rival products. A number of application developments replaced the native OpenROAD TableField header by a more visually acceptable StackField-based pseudo-header, whose contents were manually adjusted to align with the TableField columns. In many cases, the application code included specific references to these pseudo-header fields.

Font-mapping changes starting in OpenROAD 4.0 and beyond caused virtually all such pseudo-headers to become misaligned unacceptably, and application changes became necessary.

RESOLUTION: Redefining the TF_SYSTEM font in appedtt.ff (or the font file referenced by II_FONT_FILE, if defined), may resolve this problem. You can reset it to the font specified in the OpenROAD 3.5 installation (not recommended), or you can switch it to Arial. This solution will change all fields that currently use TF_SYSTEM; be sure that the result is acceptable.

1. Make a copy of the appedtt.ff file (or the font file referenced by II_FONT_FILE, if defined) in your OpenROAD 3.5 installation (\ingres\files\appedtt.ff). Name it something like appedtt_latest.ff.

2. Edit this file and replace the font name used in the six definition lines supplied for TF_SYSTEM with the name “arial”. Save and close the file.

3. In a command window on your OpenROAD 5.1 installation (that is, with the II_SYSTEM appropriate to that installation), issue the following command so that OpenROAD will use your new file:

4. Run your application from OpenROAD Workbench. Check that the TableField pseudo-headers are correctly aligned and that the effect on other fields remains acceptable. If not, re-edit the appedtt_latest.ff file and the corresponding file in your OpenROAD 3.5 installation. Copy the six definition lines supplied for TF_SYSTEM from the 3.5 file, and use them to replace the corresponding six lines in the 5.1 file.

5. Re-run your application from Workbench. Check that the TableField pseudo-headers are correctly aligned and that the effect on other fields remains acceptable.

If redefining the TF_SYSTEM font does not resolve this problem, you will need to adjust the field widths in the pseudo-headers to realign the fields.

Identifying and manually adjusting pseudo-headers is painstaking and slow. Using an adapted crawler tool is undoubtedly more cost-effective, but it will need to be adapted and tested to match the pseudo-header implementation. In this situation we recommend that you engage Actian Services to assist with the conversion (http://supportservices.actian.com/support-services/support#contacts).

This timezone issue is related to date datatypes. This issue will affect you only if your application has time data from multiple timezones (typically timetables).

ISSUE: OpenROAD 3.5 uses absolute timezone handling based on the Ingres 6.4 model; this has certain built-in inaccuracies, and later versions of Ingres (and OpenROAD 4.0 onward) use timezone information tables that are accurate.

Consequently, OpenROAD 3.5 applications handling time data as described previously typically have workaround code to correct the client data (otherwise a French train leaves an hour before the English client application says it will).

RESOLUTION: Upgrades to the latest version of OpenROAD must disable the workarounds wherever they occur in the code.

The following issue concerning nullable declarations is related to code.

Note: If your application code has been policed well and routinely declares scalar variables as not null unless a null value is absolutely necessary, you may skip this section.

If your code contains many instances where “not null” has been omitted from declarations, you should consider this issue carefully.

ISSUE: In all versions of OpenROAD, all scalar field variables, global variables, and userclass attributes are by default not null; however, variables declared in the code are by default nullable, in accordance with the ANSI standard.

Up to OpenROAD 3.5, statements where the value of a nullable variable was assigned to a not-null variable or attribute were tacitly tolerated, despite the fact that they could fail at runtime. Likewise, substitutions in SQL statements could be done using nullable variables, despite the risk of failure.

However, this practice is inconsistent with OpenROAD’s core policy of highlighting the maximum number of potential errors at compile time, when they are easiest to diagnose and fix. Accordingly, from OpenROAD 4.0 onward, such statements generate a warning (or for SQL statements, an error) at compile time.

RESOLUTION: The most robust solution, which is to locate and change all scalar nullable declarations in the code, can be automated. (Actian Services has such a tool.) However, if there are any dependencies in the code along the lines of “if this_variable is null then...,” the code is broken; such dependencies are likely to exist in at least a few places.

You cannot simply correct the declarations of variables that throw a warning or error; in many cases the effect is simply to move the warning or error one step back in a chain of assignments, while widening the net of dependencies.

The only negligible-risk approach is to apply the ifnull function to every statement throwing a warning. This cannot be automated. (Many clients have chosen to tolerate the warnings that are created whenever they compile or build their applications rather than engage in large-scale correction.)

For SQL errors, slightly more extensive recoding is necessary and also manual.

To apply ifnull to statements that are causing a nullability warning, and to fix SQL statements that are causing a nullability error

1. Compile the application (with force compile set) and copy w4gl.log from ingres\files to applicationname.log. Open the log file. In Workbench, view the components of the application.

• Apply ifnull according to the datatype. For example, if in the following statement “nullable_var” is of datatype varchar:

c. Add a code line before the error statement that copies the nullable variable, ifnulled, into a companion not null variable (same name, suffixed with ‘_nn’, for example); then alter the error statement to use the notnull variable. For example, if the error statement is:

ISSUE: In Ingres 9.1.1, the return value of the CHAREXTRACT() function was changed from a nullable char(1) to a nullable varchar(4) to support multi-byte languages and the UTF-8 character set. This could cause some unexpected side effects.

For example, in the following code fragment, you could get different results between previous versions of Ingres and OpenROAD and Ingres 9.1.1 or later and OpenROAD 5.1:

In previous versions of Ingres and OpenROAD, av contained ‘abc’ with a length equal to three. In Ingres 9.1.1 or later and OpenROAD 5.1, av contains ‘ab c’ with a length equal to six.

If you have a local installation of OpenROAD 5.1 with Ingres 9.1.1 or later, and this version of OpenROAD also runs against a remote Ingres Server 9.0.4 or earlier, you will see differences in return types from the two Ingres versions.

RESOLUTION: If your application handles only single-byte characters, you can use BYTEEXTRACT() to replace CHAREXTRACT() to resolve the issue; otherwise, you must fix your application.

The following issues are related to database drivers.

If you are connecting to a non-Ingres database using one of the provided drivers, you will need to change your application to use the corresponding Enterprise Access component (these are used extensively by applications already running on OpenROAD 4.0 and above).

ISSUE: OpenROAD 4.0 and above provides no support for specific database drivers to non-Ingres DBMSs.

RESOLUTION: The Enterprise Access components provide specific high-performance, high-functionality interfaces to a more complete set of DBMSs.

If you are using a database driver, Knowledge Base document 355675 at the Customer Portal (https://support.actian.com) provides detailed guidance about using Enterprise Access with OpenROAD.

For additional guidance concerning how to upgrade your driver-based applications, contact Actian Support (http://supportservices.actian.com/support-services/support#contacts).

The following issues are related to operating system platforms.

You need to consider this issue only if your application runs on both UNIX and Windows platforms, and uses CurSession.WindowSystem (rather than CurSession.OperatingSystem) to determine the operating system. The correction involves three lines of code.

ISSUE: In versions of OpenROAD since OpenROAD 4.0, the CurSession.WindowSystem setting for UNIX platforms is set to WI_MSWIN32, not WI_MOTIF, reflecting that OpenROAD is running on a pseudo-Windows environment—Mainsoft—rather than on UNIX itself, so that the features available to it will be "Windows" ones. Developers who want to determine whether they are hosted on UNIX use the CurSession.OperatingSystem setting to look for SY_UNIX.

However, some OpenROAD 3.5 applications deployed to both UNIX and Windows platforms have tested CurSession.WindowSystem for a WI_MOTIF setting rather than testing CurSession.OperatingSystem for SY_UNIX. This will not work when they are converted to the current release of OpenROAD.

RESOLUTION: Because of this, in the current release of OpenROAD (but not OpenROAD 4.x) the CurSession.WindowSystem attribute is ReadWrite, and can be reset in the code from WI_MSWIN32 to WI_MOTIF when the application starts. Thereafter, any code that tests CurSession.WindowSystem will distinguish a Windows host from a UNIX host.

1. In OpenROAD Workbench, open the starting component of your application and edit its script.

2. Immediately after the "begin" (or "{") statement of the initialize or procedure block, insert the following three lines of code:

If you want your converted applications to display the same way (as closely as possible) on both UNIX and Windows, read this section.

ISSUE: The available UNIX fonts differ in slight but discernible respects from their Windows counterparts.

RESOLUTION: You can use II_FONT_FILE to ensure that your UNIX application uses the same font definitions as your Windows application, but the TF_SYSTEM fonts will not map well.

1. Set II_FONT_FILE to point to the default font file (appedtt.ff), or the version of it that you are using on Windows.

2. Change the TF_SYSTEM setting in your choice of font file from “MS Sans Serif” (which maps poorly on UNIX) to “arial”.

If you still experience problems, read Actian Knowledge Document 272124 (https://servicedesk.actian.com) for further suggestions.

The following issues are related specifically to UNIX platforms.

If your 3.5 application specified UNIX-specific fonts, you will need to review and probably change your font file when you upgrade to the latest version of OpenROAD. (Also see Fonts in Mixed UNIX/Windows Environments.)

ISSUE: The default fonts specified in the OpenROAD font file appedtt.ff are now Windows fonts.

RESOLUTION: You may overwrite these definitions, but exercise care when doing so.

2. Replace the font names with the appropriate UNIX font name (“-*-lucida-medium-r-*-*-*-120-*” for example). Ensure that the order of the changed fonts is appropriate to the font sizes in the file.

4. If you already had your own font file in OpenROAD 3.5, review and change it to ensure that the order of the fonts exactly matches the appedtt.ff font order.

If you want the trace output to continue to go to stdout, you must change the application command line.

ISSUE: Log/trace output no longer goes to stdout in OpenROAD 2006 and later. Instead, there is a trace window and a trace w4gl.log file.

RESOLUTION: You can override the destination in the command line.

For more information about command flags, see the latest OpenROAD Workbench User Guide.

If you have 3GL libraries, you will need to change the way you build them.

ISSUE: make3gllib no longer exists.

RESOLUTION: In the OpenROAD installation $II_SYSTEM/ingres/w4glsamp directory, there is a 3GL sample. Use this example and the instructions provided to build your 3GL libraries in the latest version of OpenROAD.

Although its use is unsupported, some OpenROAD 3.5 applications pass the WidgetId in XWindows calls. If your application does this, you will need to make changes.

ISSUE: Now that OpenROAD on UNIX runs using MainWin, using the WidgetId in this way will no longer work without changes.

RESOLUTION: Open a call with Actian Service Desk (https://servicedesk.actian.com), as any solution will be different for different applications.