The Health Check wizard must be run when upgrading in order to evaluate your instance’s ability to move to the target version. During the health check, various types of issues may be detected which can affect your ability to upgrade. This article will cover how to resolve a “Type change” error reported by the health check.
This error generates an output similar to the following in health check:
This error results when a stock field in the application has had its expected field type altered via a code-level customization. In this example, the field identified in the health check error is extended in the
./custom/Extension/modules/Opportunities/Ext/Vardefs/sugarfield_next_step.php file. The following line in the file is causing the error:
The next_step field type is defined as “text” and not the expected stock value of “varchar”. To address this issue, you must first decide if you want to preserve the existing data in the field since it may not be compatible with the expected field type. For instance, a “text” type field can save a significantly large amount of data in the field and that data would be truncated upon reverting it to the “varchar” field which can only hold a maximum of 255 characters.
If you wish to preserve the data, we recommend creating a field in Studio (e.g. next_step_custom_c) in the same module with the field type set to the custom value. Once the field is created, you can then migrate all of the data from the stock field with the following queries:
# Ensure all current records in the parent table have a corresponding record in the custom table
INSERT INTO opportunities_cstm (id_c) SELECT id FROM opportunities WHERE id NOT IN ( SELECT id_c FROM opportunities_cstm );
# Copy data from the stock field to the custom field
UPDATE opportunities_cstm LEFT JOIN opportunities ON id_c = id SET next_step_custom_c = next_step WHERE 1;
# Delete data from the stock field
UPDATE opportunities SET next_step = NULL WHERE next_step IS NOT NULL;
Once the data is migrated or if you wish to just revert the field type with out migrating data, you will need to disable the file setting the unexpected field type. To disable the file, we recommend placing the file in a directory called “Disabled” contained within the current directory of the file. In this example, you the new directory path for the offending file would be
Once the necessary changes have been made, please navigate to Admin > Repair and perform a “Quick Repair and Rebuild”. After the Quick Repair and Rebuild finishes, click the Execute button at the bottom of the page to run the database updates, which will change the field type back to the expected stock value. Then, perform the health check again to confirm that the error is no longer reported.