Additional enhancements

Null values allowed in non-key validated columns

It is now allowed to store null values in a validated column, meaning that the column can contain valid values from the assigned lookup column and null (blank) values. If you want to allow null values in a validated column, the default value of the column must be null. Generally speaking, this should only be done when the null values have a specific understood meaning for your data, such as unassigned or inapplicable.

Although Axiom Software used to require the default value of a validated column to be a valid lookup value when you first assigned the lookup column, it was possible to later edit the validated column to change the default value to null. So this behavior change could potentially affect existing columns, though the situation should be rare. In previous versions there would have been no reason to change the default value to null, because null would not have been allowed when saving and would have caused an error.

If you have an existing validated column with a null default value, and the column is omitted from the save when creating new records, or if it is included in the save but left blank (for non-string columns), the save now uses the default value of null instead of causing an error due to an invalid lookup value.

NOTE: As in previous versions, we do not recommend using a null default value with a string column, whether it is validated or not. The behavior of string validated columns when using a null default value is inconsistent (due to the inability to differentiate between null and empty string in a spreadsheet), and should be avoided.

Miscellaneous

  • When using Save Type 4 with dependent saves—such as to create a column sequence and then create column sequence items—it is no longer necessary to execute this save using two separate passes. As long as the SaveStructure2DB tags are in the correct order within the file—so that the column sequence is created before attempting to create the items—the entire sequence can be created in one save-to-database process.

  • The Run QA Diagnostics test named Analyze Axiom UDFs now displays a warning if it finds any GetData functions in a form-enabled document. GetData functions should be avoided in forms whenever possible, because they will fire repeatedly during each form update.

  • The result summary page for Run QA Diagnostics tests has been updated to show total errors and warnings. The error totals are color-coded to reflect critical, major, and minor errors.