Known 4.1 Issues to Resolve
There are a number of known issues when upgrading from OpenROAD 4.1 to the current version. Some of these issues relate to workarounds or misuse of earlier versions of OpenROAD. These must be rectified when upgrading to the latest version of OpenROAD. For more information about when to correct these issues, see
Build and Run the Applications in OpenROAD 5.1.
Incorrect FP_CLEAR Field Setting
This issue is widespread, and will need to be corrected in most applications. It typically manifests as frames having areas with the wrong color.
ISSUE: In versions prior to OpenROAD 5.1 the BgPattern attribute could be set to FP_CLEAR to make the field background clear or translucent. The use of FP_CLEAR was supported only for ShapeFields, although it also worked correctly for FreeTrim fields. For all other field types its behavior was identical to BgPattern=FP_SOLID. In OpenROAD 5.1 all FormFields are documented as honoring the FP_CLEAR setting.
As a result of experimentation by developers, some field types have been left set incorrectly with BgPattern=FP_CLEAR.
RESOLUTION: Update all occurrences of fields (other than ShapeFields and FreeTrim) from BgPattern=FP_CLEAR to BgPattern=FP_SOLID.
To achieve this, Actian Corporation provides the PropertyChanger tool. To request the PropertyChanger tool, contact Actian Support at http://supportservices.actian.com/support-services/support#contacts.
To use the PropertyChanger tool on your applications
1. Download the PropertyChanger tool and unzip it.
2. Move the SourceElements.img file into your %II_SYSTEM%\ingres\w4glapps directory.
3. Import the PropertyChanger.exp file as a new application into your OpenROAD 5.1 code repository database.
Note: Before updating any of your applications, we recommend that you back them up by either exporting the affected applications or taking a checkpoint of the OpenROAD 5.1 code repository database.
To change BgPattern settings using the PropertyChanger
1. In the PropertyChanger application, examine the PropertyChanger component behavior defined for FP_CLEAR, and confirm that it takes the required action. The following is the default code provided to make this change:
/*
** Change all fields that have FP_CLEAR
** (except shapes or freetrim)
*/
IF fieldToChange.IsA(FreeTrim) = TRUE THEN
ELSEIF fieldToChange.IsA(ShapeField) = TRUE THEN
ELSEIF fieldToChange.IsA(MenuField) = TRUE THEN
ELSEIF FormField(fieldToChange).BgPattern = FP_CLEAR THEN
FormField(fieldToChange).BgPattern = FP_SOLID;
ENDIF;
Modify this code as necessary to meet your requirements.
2. Run the following command from a command window:
w4gldev rundbapp yourdatabasename propertychanger
An Upgrade Assistant is displayed.
3. Using the assistant, do the following:
a. Select which applications you are correcting.
b. Specify that you want to change fields only.
c. Specify that you want to correct FP_CLEAR.
d. Specify the suffix to use if you want the assistant to make backup copies of your existing applications. Leave this blank if you do not want backup copies to be made (for example, if you have backed up your applications elsewhere).
e. Click Upgrade to make the changes.
4. Compile and run the applications to confirm that the FP_CLEAR problems are corrected and these changes have caused no new issues.
If you created backup copies using the Upgrade Assistant, delete them after you are satisfied that the changes are correct.
Note: Review the next issue,
Incorrect Field Colors, to determine whether you need to use PropertyChanger again. If not, remove the SourceElements.img image file and the imported PropertyChanger application.
Incorrect Field Colors
If you are using a site-specific color definition file for OpenROAD, this issue may not affect your applications.
This issue typically manifests itself as display areas showing the “wrong gray” when the developer starts adjusting field positions, margins, and transparency.
ISSUE: OpenROAD changed the color definitions it used between OpenROAD 3.5 and OpenROAD 4.0. These definitions have not changed since. For systems already on OpenROAD 4.x, visible color issues will have been resolved already. However, a potential problem remains with the varieties of gray.
In applications developed initially in OpenROAD 3.x, CC_PALE_GRAY and CC_LIGHT_GRAY were identical, and many fields were set to one or the other indiscriminately. When those applications were upgraded to OpenROAD 4.x, fields not visible to the developer—generally composite fields—were not always corrected.
The definition of CC_SYS_BTNFACE also changed over time: on Windows NT 4 the buttonface color was defined as rgb(192,192,192). It is now rgb(212,208,200).
In the upgrade to the current version of OpenROAD, fields that have these color problems may not be visible initially. They may become evident only when changing to a background of FP_CLEAR or when changes are made to composite field margins.
Note: Any references to CC_LIGHT_GRAY (or CC_SYS_BTNFACE) in the original 3.5 code logic that might be broken by making the following change should have been found and resolved during the previous upgrade to 4.x. If you suspect that it has not been fixed, do not make the following change.
RESOLUTION: You can standardize color attributes using the PropertyChanger tool. The following procedure assumes that you have already loaded the PropertyChanger tool into your OpenROAD project (see "To use the PropertyChanger tool on your applications" in
Incorrect FP_CLEAR Field Setting). For more information, see
Upgrading Applications with the PropertyChanger Utility.
Note: Before updating any of your applications, we recommend that you back them up by either exporting the affected applications or taking a checkpoint of the OpenROAD 5.1 code repository database.
To change field colors using the PropertyChanger
1. In the application, examine the PropertyChanger component behavior defined for CC_LIGHT_GRAY, CC_PALE_GRAY, and CC_SYS_BTNFACE, and confirm that it takes the action you require. The following is the default code provided to make this change:
/*
** Change all fields that have CC_LIGHT_GRAY to
** CC_PALE_GRAY.
** (but ensure tablefield reset does not override its
** columns, tablebody, tableheader)
**
** Change all fields that have
** CC_SYS_BTNFACE to CC_PALE_GRAY.
** (disabled – only enable if the platform you are currently
** deployed on uses rgb(192,192,192) and you want to preserve
** that shade of gray)
*/
IF fieldToChange.BgColor != CC_LIGHT_GRAY
/* AND fieldToChange.BgColor != CC_SYS_BTNFACE */
THEN
/* do nothing */;
ELSEIF fieldToChange.IsA(TableField) != TRUE THEN
fieldToChange.BgColor = CC_PALE_GRAY;
ELSE
tbl = fieldToChange;
copiedTbl = tbl.Duplicate();
tbl.BgColor = CC_PALE_GRAY;
tbl.TableBody.BgColor = copiedTbl.TableBody.BgColor;
IF tbl.TableHeader IS NOT NULL THEN
tbl.TableHeader.BgColor = copiedTbl.TableHeader.BgColor;
ENDIF;
FOR i = 1 TO tbl.TableBody.ChildFields.LastRow DO
col = tbl.TableBody.ChildFields[i];
copiedCol = copiedTbl.TableBody.ChildFields[i];
col.BgColor = copiedCol.BgColor;
IF col.TitleTrim IS NOT NULL THEN
col.TitleTrim.BgColor = copiedCol.TitleTrim.BgColor;
ENDIF;
ENDFOR;
ENDIF;
Modify this code as necessary to meet your requirements.
2. Run the following command from a command window:
w4gldev rundbapp yourdatabasename propertychanger
An Upgrade Assistant is displayed.
3. Using the assistant, do the following:
a. Select which applications you are correcting.
b. Specify that you want to change fields only.
c. Specify that you want to correct Gray Color Settings.
d. Specify the suffix to use if you want the assistant to make backup copies of your existing applications. Leave this blank if you do not want backup copies to be made (for example, if you have backed up your applications elsewhere).
e. Click Upgrade to make the changes.
4. Compile and run the applications to confirm that the color problems have been corrected and these changes have caused no new issues.
If you created backup copies using the Upgrade Assistant, delete them after you are satisfied that the changes are correct.
Note: When you are done using them, remove the SourceElements.img image file and the imported PropertyChanger application from your OpenROAD project.
Incorrect Truncation of Date-times
This issue manifests as incorrect truncation of date-times. It is therefore difficult to detect, but can be anticipated and avoided as detailed below.
This issue does not affect your OpenROAD applications or require changes to them. However, it may affect the rollout of the OpenROAD 5.1 upgrade to client machines in OpenROAD client/OpenROAD Server architectures, if you are upgrading from versions prior to OpenROAD 4.1 Service Pack 3.
ISSUE: OpenROAD 4.1 SP3 and OpenROAD 5.1 use different versions of the Ingres shared libraries and Ingres Net from OpenROAD 4.1 SP2 or previous versions. The newer libraries and Ingres Net contain changes to how they handle certain data types and functions to conform to ANSI database standards. In particular, the handling of “date without time” has changed.
Because OpenROAD is built and installed with a particular version of Ingres Net, OpenROAD clients and application servers can only communicate dates without time to each other if they are both pre-OpenROAD 4.1 SP3, or both post-OpenROAD 4.1 SP2.
RESOLUTION: All OpenROAD clients and servers that inter-communicate must be upgraded together, and rolled back together.
Remember to preserve an application maintenance capability in both current and target OpenROAD versions, so that both rollout and rollback can be handled successfully.
Change in Handling of Synchronous ActiveX Events
Note: This issue affects only applications using ActiveX components. It does not affect those upgrading from OpenROAD 4.1 SP3. It also does not affect applications that have no ON EXTCLASSEVENT code blocks.
This issue manifests in a variety of ways, and unpredictably. It is therefore difficult to detect, but can be anticipated and avoided as detailed below.
ISSUE: A change introduced in OpenROAD 4.1 SP3 resulted in the current version of OpenROAD handling ActiveX events differently from OpenROAD 4.1 SP2 or previous releases.
Prior to OpenROAD 4.1 SP3, when a frame invoked an ActiveX component that generated events (Internet Explorer generates many progress-related events), those events went to the end of the OpenROAD queue. Although this was simple to handle, in many situations the information arrived too late to be useful.
From OpenROAD 4.1 SP3 and forward, these events were handled immediately when they were received, similar to .NET and Visual Basic. When such an event is received the next statement executed is the first code statement associated with that event. This means that where ActiveX events are involved, developers can no longer rely on the “single thread principle” that no event will start until the current event has completed.
The following scenarios can result in a change of behavior when upgrading to the current version of OpenROAD. Changes will be necessary if:
• The code in an ActiveX event block depends on OpenROAD code having been executed since the ActiveX component was invoked
• The code in an ActiveX event block itself invokes, directly or indirectly, an ActiveX component whose events trigger some other OpenROAD code
RESOLUTION: Identify all such cases in your applications. A simple code change corrects most cases by effectively restoring the behavior prior to the upgrade.
Split the ON EXTCLASSEVENT code block into two code blocks by inserting extra code into the code block, immediately after the BEGIN (or "{") statement, as illustrated in the following example.
• Code BEFORE upgrade:
ON EXTCLASSEVENT 'StatusTextChange'
(
p_v_text = VARCHAR(256) NOT NULL;
)=
BEGIN
// … do stuff …
END;
• Code AFTER upgrade:
ON EXTCLASSEVENT 'StatusTextChange'
(
p_v_text = VARCHAR(256) NOT NULL;
)=
BEGIN
CurFrame.SendUserEvent('XEvent StatusTextChange',p_v_text=p_v_text);
END;
ON USEREVENT 'XEvent StatusTextChange'
(
p_v_text = VARCHAR(256) NOT NULL;
)=
BEGIN
// … do stuff …
END;
UNIX Installation Error
This issue affects only applications running on UNIX operating systems. This issue manifests as an OpenROAD installation error.
ISSUE: OpenROAD 2006 is built on MainWin 5.1.1. This version of MainWin has different core services and system requirements than OpenROAD 4.1, which is built on MainWin 5.0.2. These differences will affect installation both on rollout and rollback.
RESOLUTION: Ensure that you have established and built the uninstallation and installation requirements into your rollout processing.
Ingres Result Type Differences
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:
av = varchar(10) not null;
av = ‘a’ + Pad(charextract(‘abc’, 2)) + ‘c’;
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.
Building C Code Containing EXEC SQL Commands
ISSUE: Problems result when you build *.c files from *.sc files that contain EXEC SQL (ESQL/C) commands using esqlc. If you use esqlc, it could produce C code incompatible with OpenROAD. This is why esqlcor is shipped with OpenROAD 5.0 and later.
RESOLUTION: Use esqlcor to build your *.c files instead of esqlc to pre-process ESQL/C applications.
For more information and instructions to use esqlcor in building C files, see the Readme_4GLsample.txt file in $II_SYSTEM/ingres/w4glsamp/esqlc.