When a multi-value link has been configured with a primary join—which is the typical situation—there are circumstances in which the foreign key used by this join to identify the primary record is unable to find the primary. For example, this can happen when the primary record has been deleted from the multi-value group or the multi-value group is newly created and has no records. In such cases, the multi-value link can be configured to update the primary foreign key to a value of NULL, or to a special value of NoMatchRowId, depending on your requirements. This behavior is configured through the Check No Match property of the Multi Value Link object type, and has performance consequences.
The purpose of the special NoMatchRowId value is to prevent secondary queries on foreign key values that are known to have failed, thereby improving performance, much in the same way that using a primary join improves performance.
The NoMatchRowId generating and testing behavior is activated by setting Check No Match to FALSE for the MVL. This setting has the following results:
When the application encounters a master record where the primary foreign key is NULL or invalid, it performs a secondary query to determine if there are detail records in the multi-value group. If it finds there are no detail records, it sets the primary ID field to the special value NoMatchRowId.
When the application encounters a master record where the primary foreign key has the value "NoMatchRowId," this indicates to the system that there are no detail records in the multi-value group and the secondary query is not performed.
If you set Check No Match to TRUE, the Siebel application will perform a secondary query whenever the outer join on the primary fails, or is set to NULL or NoMatchRowId. If the secondary query finds a matching detail record, it updates the foreign key with that record's row ID, provided the MVL has an Auto Primary property setting of DEFAULT. If no matching child record is found, or Auto Primary is set to NONE, the application leaves the existing value intact.
A Check No Match setting of TRUE can have serious negative performance consequences. If a multi-value group is sparsely populated (that is, most master records do not have any detail records in the multi-value group) and has Check No Match set to TRUE, it will be almost as slow as not having a primary join at all.
Check No Match should be set to FALSE for most multi-value links because of the performance consequences. It should only be set to TRUE if the multi-value group could possibly have records added to it without going through the MVG itself. For example, account addresses might actually be inserted by means of the Business Address multi-value group on the Contact business component instead of the Address multi-value group on the Account business component. Also, if records can be added to the detail business component through EIM, the TRUE setting is the appropriate one.
The Use Primary Join property should be set to TRUE if CheckNoMatch is TRUE. If CheckNoMatch is set to TRUE and Use Primary Join is FALSE, then the Siebel application will always do the secondary query to find the child records.