Upgrade considerations

Please review the considerations in this section before upgrading to version 2019.3. If you have any questions or if you need assistance with upgrading, please contact Axiom Support.

IMPORTANT: This document details the upgrade considerations when moving from the most recent Axiom Software release of 2019.2 to the new release of 2019.3. If you are upgrading from an earlier version, please also see the release notes for the interim versions for any additional upgrade considerations.

Advance notice: planned removal of deprecated Workflow feature

Description

The Workflow feature was replaced several years ago by plan file processes in Process Management. Workflow was deprecated and hidden in all systems, except in existing systems that were actively using it. Since that time, it has been supported for backward-compatibility only, to give clients time to migrate to the new feature.

We are now giving advance notice that we plan to remove the deprecated Workflow feature as of version 2020.1. Removing deprecated features helps to simplify our development and testing efforts.

Testing and Review

In our understanding, most or all clients have already migrated to using plan file processes. However, if any clients are still using workflow, you should migrate the workflow to a plan file process at your earliest convenience.

If you have any concerns about the planned removal of this deprecated feature, please contact Axiom Support.

Advance notice: planned removal of deprecated Data Explorer feature

Description

The Data Explorer feature has been deprecated in favor of the existing Web Reports feature and the developing Axiom Intelligence reporting feature. Since the introduction of the browser-based Report Builder in 2018.1, Data Explorer has been supported for backward-compatibility only.

We are now giving advance notice that we plan to remove the deprecated Data Explorer feature as of version 2020.1. Removing deprecated features helps to simplify our development and testing efforts.

Testing and Review

In our understanding, most clients have already discontinued use of Data Explorer. If you have any concerns about the planned removal of this deprecated feature, please contact Axiom Support.

Change to default save-to-database behavior

Description

The default behavior for processing save-to-database blocks in an Axiom file has been updated so that saves are now processed concurrently instead of sequentially. This change in behavior may improve file performance for files with many save blocks, or for files with multiple save blocks that handle many records.

The new behavior includes automatic exceptions for save blocks that may have dependencies—for example, when saving new records to a reference table and then referencing those new records in a subsequent save block, or when a save block triggers an Axiom query before saving. Because these dependent cases are automatically handled, no new save errors should occur as a result of this change.

Additionally, because save blocks are now processed concurrently, the point at which the save-to-database process stops due to error may be different. In previous releases, Axiom Software stopped processing save blocks after encountering the first error. Because multiple save blocks may already be in process when an error is encountered, those processes will continue. However, no new save blocks will begin processing after the error.

For more information, see Run save-to-database processes concurrently.

Testing and Review

We do not believe this change in behavior will have any adverse impact on existing customers. If you have existing Axiom files with known save dependencies, you can test these files after upgrading to ensure they still work as expected. If an edge case is identified that the new behavior does not handle, it is possible to disable the new behavior on a per file or system-wide basis:

  • Per File: To disable the new behavior for a particular file, set Enable Parallel Save Data to Off on the Control Sheet. For existing files, you must upgrade your Control Sheet to gain access to this setting.

  • System-Wide: To disable the new behavior for an entire system, set the system configuration setting ParallelSaveEnabled to FALSE. For information on how to modify the system configuration settings, see System configuration settings.

Behavior change for virtual spreadsheet plan files

Description

When using virtual plan files, the file itself is never saved—only data can be saved. If a user opens a virtual spreadsheet plan file in the Desktop Client, the file is now flagged as "R/O" on the file tab if the user cannot save data for any reason. This is meant to provide a signal to the user that they cannot save any changes to the plan file.

Additionally, if a user has Read/Write access to the virtual spreadsheet plan file, Axiom Software now locks the plan file when the user opens it with the ability to save data, in order to prevent other users from saving data in the file at the same time. When process management elevates user permissions, it grants Read/Write access with Allow Save Data, so the new behavior will automatically apply to step owners. However, if you want some users to have edit permissions at all times (not just when they are the step owner), then it is recommended to grant those users Read/Write with Allow Save Data to the virtual plan files instead of just Read-Only with Allow Save Data.

NOTE: This new behavior does not apply to virtual form-enabled plan files. File locking does not apply to Axiom forms, and Axiom forms are not flagged as read-only. If you want to control data saves in form-enabled plan files, the existing save locking feature for Axiom forms can be used. The behavior of virtual form-enabled plan files is unchanged.

Testing and Review

This change only affects customers who have implemented virtual spreadsheet plan files. This is an uncommon configuration, as most virtual plan files are form-enabled plan files. If you are using virtual spreadsheet plan files, you should review your security configuration for the file group to ensure that any users whom you want to have full access at all times (not just when they are step owners) are granted Read/Write access instead of Read-Only.

Behavior change to allow null values in validated columns

Description

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.

Testing and Review

It should be rare for any existing validated columns to have a null default value, therefore most customers should be unaffected by this change. If you suspect that you may have a validated column that would be affected by this change, open the table editor and check the Default Value of the column in the column properties. If it is null and you do not want to allow null values in the column, change the default value.

Behavior change to imports affecting string columns with null default values

Description

As part of enhancements made to imports and column default values in this release, a behavior change was introduced in imports that affects the following extremely rare configuration:

  • The source for the import is a database rather than a file
  • One of the columns in the destination table for the import is a string column
  • The default value for the string column is null (blank) rather than '' (empty string)

If the import creates new records or updates existing records with the mapped string column, and the import source data is null, the string column is now populated with null values instead of empty string values. This could potentially cause issues when querying the table data in Axiom Software, because null records and empty string records are not treated the same way. For example, a filter such as Acct.Category <> '' would filter out records with empty strings in the Category column, but not records with null values (that would require a filter of Acct.Category is Null).

The affected configuration is rare because having a null default value for a string column is discouraged in the application and documented as not recommended. By default, string columns use a default value of '' (empty string) unless this is explicitly changed. When saving data from a file, Axiom Software cannot distinguish between null and empty string, and therefore blank values are saved as empty string. Using the default value of empty string for string columns provides consistent treatment of blank values.

If you have a column that is affected by this change, the recommended solution is to edit the column properties to change the default value to empty string rather than null.

Testing and Review

This issue only affects customers with the described configuration, which should be extremely rare or non-existent. If you suspect that you may have a string column that would be affected by this change, open the table editor and check the Default Value of the column in the column properties. If the default value is null (blank), and there is no known reason why a null default value is being used, it should be safe to change the default value to empty string. Empty string is specified by entering two single quotation marks as '' (not one double quotation mark). If you have any concerns about this change or need assistance, please contact Axiom Support.

Potential impacts on end users

This section summarizes the potential impacts to your end users when upgrading to version 2019.3. This list is provided to help you understand changes that you may need to communicate to end users. You may also need to update your internal documentation.

  • If you are using virtual spreadsheet plan files, the plan file is now flagged as "R/O" if the user does not have the ability to save data in the plan file.

NOTE: "End users" refers to users who work with plan files and reports that have been built for them. These users do not perform any file setup activities or administration activities. It is assumed that Master System Users will fully review the release documents to understand changes that may affect them and other power users.