Handling of Invalid Objects¶
This page provides information on how to handle invalid database objects in IFS Cloud.
Some invalid objects can appear after an upgrade/delivery and the clean scripts for active components have been deployed. First try to recompile invalid objects. If invalids still exists, follow the guidelines below.
When upgrading, there is a risk that configurations for custom objects become invalid. This is the case when you have invalid objects which has a name with one of the following suffixes: _CFV, _CFP, _ICV, _ICP, _CLV, or _CLP. In order to correct those, you have to manually address each problematic custom object.
Read-Only Custom Objects with invalid definition¶
For read-only custom objects, you have to review unpublished custom fields, information cards or custom logical units. These can be found using the Custom Objects overview page. If only the objects used in the definition of the custom object has changed, you can update the definition accordingly and publish the custom object to make the corresponding invalid object valid.
Custom Objects where parent LU has changed¶
Custom fields and information cards are always connected to a parent LU. If the parent LU has changed, you have to define new custom fields or information cards on the new LU. If there is persistent data on custom fields, that has to be migrated to the new custom field. Afterwards, the invalid objects should be manually removed.
Handle LU Modifications¶
LU Modifications between IFS Application versions will be handled by custom_obj_sys.Handle_Lu_Modification. This method will update the Objects related to Custom Logical Units, Custom Fields and Information Cards. The user will need to manually update other Custom Objects.
Business Reporting & Analysis Services¶
Access Views are on-demand created views that serve as read interfaces for the Analysis Models. If an upgrade is performed from an earlier version of IFS Cloud where Access Views have been used, there is a risk that some of the Access Views are invalid after the upgrade. The general main reason is that the referenced source views have changed.
There is no automatic recreate task started during the upgrade since it must always be investigated if it is possible or not to recreate invalid Access Views. If an Access View is recreated it is necessary that the definition of the view is compatible with the associated tabular data source in the Analysis Models specific SQL Server database.
To handle the case where Access Views are considered as invalid database objects:
- Use the script biaxsv_Recreate_Db_Invalids_From_Src.sql in the folder manualdeploy\database\biaxsv to recreate all Access Views considered as invalid database objects. The script will only consider Access Views where the object status is Invalid in the database.
It is still important to be aware of the fact that, once an Access View has been recreated, it might not be compatible with the Analysis Models definitions.
Note: The script might fail to recreate some of the Access Views. If there are any views with status Invalid in the Access Views page after the script-execution, go to the Access View page and perform action Validate and use the Info field to get an idea about what the problem is.
To handle the case where Access Views are considered as in invalid by the External Access framework:
- Use the Access Views page Select the Access Views and then go to theAccess View page and perform Validate and use the Info field to get an idea about what the problem is.
All Materialized Views with a status (staleness) other than UNUSABLE be marked as active during an upgrade.
When the installation has finished, there might be Materialized Views that are not valid, i.e. considered as invalid database objects. There is currently no automatic mechanism that can reduce the number of invalids. The reason for a Materialized View to become invalid might be due to changes to referenced tables without recreating the Materialized View. One way of handling this is to use the existing Data Mart Sources page and to do a manual refresh. The refresh mechanism will try to recreate a Materialized View that is marked as having a compilation error status.
Note: Since previously used Materialized Views, during the update are marked as active, this means that even if the staleness after upgrade is UNUSABLE, such Materialized Views will be refreshed next time a refresh schedule, containing the Materialized Views, is executed. It is thus not necessary to manually Activate these Materialized Views.