Using the Check No Match Property with a Primary Join

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.

How to set the color, disable, hide and text style property for a control at runtime

Prior to version 6, users could not change the property values of a control during runtime. In Siebel Enterprise version 6, a new method named 'SetProperty' was introduced; this method is used to change the following visual properties of a control:
Background Color - Must state the RGB value
Foreground Color - Must state the RGB value
Text Style - Example: Bold, Underlined etc
Enabled - True or False (used to activate or inactivate a control)
Shown - True or False (used to make a control visible or invisible)
Limitations:
1. The 'SetProperty' method may only be used to change the visual properties of controls that reside in a form applet. The method cannot identify a 'control' within a list applet because according to the application the 'list' part of the applet is a control and therefore cannot distinguish the fields within. Change Request12-3ANC6N has been logged as a Document Enhancement to clarify this information in the Bookshelf.
2. In the Siebel Enterprise version 6.X documentation for SetProperty it shows
oControl.SetProperty(propName, propValue)
The parenthesis should not be included as it generates a syntax error. It should therefore be removed as it causes confusion.
The correct syntax isoControl.SetProperty "propName", "propValue"
Change Request 12-1U0S1D has been logged as a Documentation Enhancement to address this.
Example:
The Siebel Visual Basic (VB) code below is placed in the PreSetFieldValue event in the 'Action' business component. When the user changes a value in the Activity Option Applet the 'Priority' field's background colour changes.
Dim applet As AppletDim control As Control
Set applet = theApplication.ActiveAppletSet control = applet.FindControl("Priority")control.SetProperty "BackgroundColor", "215 152 4"
There are further eScript examples in Bookshelf V6 section 'Siebel Object Interfaces Reference' Chapter 3 Page 3-231.
As mentioned in Bookshelf, if more than one property is to be set, each must be set in a separate statement.The SetProperty method is not supported in Siebel7.0.x. The SetProperty method is available for browser scripts in Siebel 7.5 for the following controls: CheckBox, ComboBox, TextBox, Text Area and Label. Change Request 12-DP6B5G has been logged as an Enhancement Request to allow this method to work with button controls.