This page provides information on how to handle invalid database objects in IFS Applications 10.
Some invalid objects can appear after an upgrade/delivery and the drop scripts for obsolete components 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.
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 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.
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.
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 Applications where the BI Analysis Package extension has been used, there is a risk that some of the Access Views are invalid after the upgrade. The main reason is that the referenced source views has changed. An Access View can be invalid in two ways; either as an invalid object in the database or invalid in the sense that the Access View is not compatible with its references source view.
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 SSIS packages and database tables in SQL Server where the IFS Data warehouse resides.
To handle the case where Access Views are considered as invalid database objects:
The script will only consider BI 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 form after the script-execution, go to the detail window and perform RMB 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:
Select the Access Views and then go to the detail window and perform RMB 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 form in IFS EE 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.