Divya a reader and member of Siebel Unleashed forum asked me a question about a common code snippet that we use in our scripting. The code snippet is as following
var oEmpBusObj = TheApplication().ActiveBusObject();
var oEmpBusComp = oEmpBusObj ().GetBusComp("Employee");
var sLoginName;
oEmpBusComp.ActivateField("Login Name");
oEmpBusComp.ClearToQuery();
oEmpBusComp.SetSearchSpec("Login Name", sLoginName);
oEmpBusComp.ExecuteQuery();
oEmpBusComp = null;
oEmpBusObj = null;
and the Question she asked is
Is it necessary that we have to write first ActivateField then followed by Clear to Query then followed by SetSearchSpec and then ExecuteQuery?
I thought of replying it there but then thought of sharing the answer with all of you so that everybody (including me) can benefit from it.
Again the answer is from my experience of working is Siebel and I might not be right or my answer might be incomplete so please don’t hesitate to express your views and correct me if I am wrong.
Answer:
Now we know that lowest layer of Siebel CRM is database layer and database understands only SQL so every action that happens on Business Layer and UI Layer has to be converted into SQL and the Script that we write at Business Layer also gets converted in SQL.
SetSearchSpec: in Script becomes part of where clause of the SQL that is going to be executed on database.
ExecuteQuery: in Script results in execution of the SQL that has been prepared.
ClearToQuery: clears any SearchSpec that might have been associated with the BC instance on which we are working.
For every SQL that is executed on database Siebel forms a Select Clause of that Query and the following fields become part of select clause
- Fields that have been marked as force active at BC
- System Fields
- Fields that have link specification as true
- The fields that have been activated in the script.
(We don’t need to use ActivateField for the above mentioned fields)
Now we are ready to answer her question.
When we issue an ExecuteQuery statement then the SQL is actually executed so it means that ActivateField has to come before ExecuteQuery at all costs.
ClearToQuery only clears the old SearchSpec associated with the current instance so it doesn’t matter if we do ClearToQuery first or ActivateField. So, in 99% cases we can safely assume sequence of ClearToQuery and ActivateField is not going to affect the results.
But there are 1% chance where it might affect the results. Those are if we use DeactivateField function on the same BC instance. Which means that in case if we
ActivateField and issue an ExecuteQuery and then instead of making BC null we use DeactivateField and then again try to ExecuteQuery on same instance then ActivateField should come before ClearToQuery but that is very rare as we usually just nullify the BC.
I hope this helps and your comments are always welcome
(6 votes, average: 4.5 out of 5)
Loading ...
5 Comments at "ActivateField ClearToQuery and ExecuteQuery"
Thanks for answering the question & must say the explanation is excellent…Great going Neel..
Hi Neel,
very good explanation !
I have to had one category of fields which are added to the selected columns implicitely, which you didn’t talk about, is obviously the shown columns.
When we work on an ActiveBusComp() for instance, every fields displayed through the applet in front of the user on the Active BC we’re working on are implicitely Activated, thus “SELECTed”, even though not marked at Force Active.
BTW, i strongly suggest to use ActivateField() in scripts to not have to think about “is my field already active”…
one last point i’m thinking of, which is probably worth an entiere article more than a single comment is the Activate Field when we DON’T use ExecuteQuery(). Actually, the doc tells not to do so, but anyway, I still see many colleagues doing this mistake. I don’t know what’s done internally, but I’ve seen scripts behaving very strangely, and when we were removing only the ActivateField calls (when they were not needed of course), all became good.
cheers,
Hi,
Nice article. I have faced similiar problems in my work too.Siebel’s expert services recommend not to set the ‘Force Active’ to true at BusComp level, as this increases the load on the server. The Activate field command in Scripting is the equivalent of this, and it is a good practise to Activate fields before querying on them. One more advantage is that upgradation will not create problems.
all wrong …
quoting a siebel review :
“The fields that are only used in Search or Sort Specifications do not need to be activated because they are not used to select from the database or store values into the database.”
A call to ActivateField is relevant only if followed by a call to the ExecuteQuery method.
Certain fields are active by default. The following list specifies BC fields that are always active:
• System fields (Id, Created, Created By, Last Updated, Last Updated By)
• Fields with their Link Specification property (on the BC object) set to TRUE
• Fields with their Force Active property (on the BC object) set to TRUE
• Fields that are included in the definition of an applet on the active view and are visible in the UI
• Fields that are used as part of a calculated field calculation when the calculated field is retrieved for use on the active applet
• Fields that are used or referenced by BC or applet user properties
• Fields that are activated with BusComp.ActivateField (strFldName). They are active for the lifetime of the BC object variable or until deactivated explicitly by the DeactivateFields method.
Application code does not need to explicitly activate the above fields with a call to ActivateField.
Comment Now!