Index

Although the best performance improvement can be seen when a column has an index created on it. However, care must be taken while deciding whether to create an index or not. Below are some of the tips to decide,
When To Create an Index
When you have large table
When the table is mainly used for queries
When you generally query the table for one or few distinct values
When large number of NULLs are in the column
When Not To Create An Index
When you have small table
When users make DML (Data Manipulation Language) changes to the table frequently
When your query results contain substantial portions of the data the table actually stores
When table is updated frequently

On Field Update Invoke

The On Field Update Invoke user property is a clean way to run some custom functionality when a BusComp field is updated. If you reflexively assume that you need to put script in the SetFieldValue event, you should consider this user property to execute your specialized functionality instead.The syntax is as follows:User Property Name: On Field Update Invoke nUser Property Value: "[FieldToCheck]", "[BusCompName]", "[MethodName]", "[Condition]"Condition is an optional parameter. If you leave it out, the method will be called any time the field is updated. If you include it, the condition must be true for the method to be invoked.FieldToCheck is also optional. If the parameter is omitted, include double quotes as a placeholder. The method will be invoked any time the BusComp is updated, as if it were called from the BusComp_WriteRecord event. If the parameter is present, the user property works just like BusComp_SetFieldValue; the update happens as soon as the cursor leaves the FieldToCheck field.Note that you can run a BusComp method on a different BusComp than the one that spawns the event. Specify the BusCompName and the MethodName. Siebel does this quite extensively (for updating child records when a parent record is updated, for example) to implement vanilla functionality. The BusComp method is invoked on another business component in the active Business Object.It is also important to understand what methods can be called from this user property. It can be used to call an eScript function. You can add eScript to the BusComp_PreInvokeMethod event to capture the invocation and call a function on the current BusComp, and from there invoke a workflow process or business service. The user property can also invoke methods on the Business Component Class that would normally be invoked through the InvokeMethod method. For example, you could call the CompleteActivity method on an Activity. Be aware of the specialized methods that are available for the class you are using.If your implementation includes Siebel Order Management, Signals can also be raised from this user property. For any of the Order Management Business Components, if a method is not found on the business component itself, Siebel will raise a signal if it exists.Whatever you choose, Siebel recommends the On Field Update Invoke user property as preferable to adding scripting to the BusComp_SetFieldValue event. The SetFieldValue event is inefficient, and even though the On Field Update Invoke user property may invoke a custom script, it can be more efficient than invoking the same script from the SetFieldValue event.

Text Lenth

One of my favorite User Properties is "Text Length Override". It is a simple technique for enforcing the length of a text field without ugly popup messages.If you have a business requirement to restrict user input to a certain number of characters, you have several options. You can find a database column that has the exact number of characters you need. You can create a field validation that will popup an error message if a user enters more characters than required. The user must correct the error condition before being allowed to step off the field. You can do something even more intrusive (with scripting, for example) to alert the user that he or she has made a mistake and/or fix the problem for them.But a completely non-intrusive, transparent, and elegant way to address the situation is to use the Text Length Override User Property on the field. Text Length Override is a User Property that corrects what almost seems to be a defect in the normal functioning of a BusComp field. It seems intuitive that a field attribute called "Text Length" would set a limit to the amount of text that could be entered into a field. Probably most people wouldn't bother to look that one up. But the fact is that Text Length does nothing at all unless combined with the Text Length Override User Property. The amount of text that a field will accept is normally determined by the size of the underlying database column.So how does this work? Suppose the following:
You have a BusComp Field called "Short Name".
The field is mapped to a column called ALIAS_NAME, which is a varchar(100).
The business requires that no more than 30 characters of text can be entered into Short Name.Here's what you need to do if you want to prevent excess text from being entered, but you don't want a validation message to interrupt the user interaction with the view:
Set the Text Length attribute on the Short Name field to 30
Create a User Property object as a child of the Field.
Set the Name attribute of the User Property to "Text Length Override".
Set the Value of the User Property to "True".*
That's all. The User Property "overrides" the normal functionality of the Text Length attribute (it normally doesn't do anything), and limits the text to the Text Length specified.

Search Specification Performance

With a web-based application such as Siebel, performance is always a primary concern, especially database performance. Database performance problems can cause ripple effects, as a bad-performing query can cause an increased load on the database, making it slow to respond to other, simpler queries. If a query runs several times (for example, when a user scrolls through a list applet, causing multiple fetches from a slow-performing cursor) database performance problems can become the Achilles heel of a Siebel implementation, and network slowdowns can compound this problem, as multiple fetches are added to multiple network round trips.
One easy way to attack database performance from the outset is by examining Search Specifications and Sort Specifications configured in your Business Components, Applets, and Pre-Defined Queries. Searches and Sorts should use indexed columns whenever possible, and you should be careful not to defeat your indexes by searching on an expression that will not use one. For example, avoid using "OR" in your search expressions, because the expression is simply copied to the WHERE clause of the query, and databases generally do a full table scan on an "OR" condition.
If you have any doubts about the performance of a particular search, compile the SRF, spool the SQL, and ask your DBA to run the explain plan. He or she can tell you if your query is performing optimally. Siebel performance can be a little bit tricky, because you don't write the SQL yourself, and you can't actually provide database hints. But when you are writing Search Expressions, you may have more control over the generated SQL than you realize