Code Related Issues
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
In OpenROAD Workbench, correct each application, as follows:
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.
2. Correct each component that has compile warnings, as follows:
a. Open the component and compile it with “ignore compile warnings” cleared.
b. Use the compile-errors window to correct each warning statement, as follows:
• Navigate to the warning, using Ctrl-W.
• Open the editor at the offending code line, using Ctrl-F7.
• Check the declared datatype of the relevant variable (or expression).
• Apply ifnull according to the datatype. For example, if in the following statement “nullable_var” is of datatype varchar:
notnull_var = nullable_var;
change the statement to:
notnull_var = IfNull(nullable_var, '');
• Navigate to the next warning using Ctrl-W, and repeat the procedure.
• Process all warning statements in this way. Recompile to ensure they are fixed.
3. Use the compile-errors window to correct each SQL error statement, as follows:
a. Navigate to the error, using F3.
b. Open the editor at the offending code line, using Ctrl-F7.
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:
UPDATE :table_name SET year = 1984;
change the code at this point to:
table_name_nn = IfNull(table_name,'');
UPDATE :table_name_nn SET year = 1984;
d. Declare the companion not null variable with the declaration of the offending variable.
e. Navigate to the next error, using F3, and repeat the procedure.
f. Process all error statements in this way. Recompile to ensure they are fixed.
4. Save and close the component.
5. Repeat with the next component until the application is clean.
6. Repeat with the other applications.