+ Start a Discussion
Rahul BorgaonkarRahul Borgaonkar 

SOQL Governor Limit Calculation

Hi,

We are using a managed package. It has custom objects (say abc) on which we have written custom trigger. In this custom trigger we have written SOQL to access managed package other related custom objects (say xyz (relates to abc)).

Does additional SOQLs written by us (on xzy) in custom trigger are counted in managed package's SOQL limits when it updates custom object (abc)?

A function in managed package is throwing Too many SOQL error and not sure it is because of our custom trigger.

Could you please help?

Thanks,

Rahul
Best Answer chosen by Rahul Borgaonkar
Abhishek BansalAbhishek Bansal
Hi Rahul,

Salesforce keeps an eye on a complete single context that is being executed by the User at a particular time.
I undertsand your scenario and would like to inform you about the basic reasons for the cause of too many SOQL queries.

May be in your trigger you have written any SOQL in a for loop and if you have not done that then may be while using an update statement on ABC object there are may triggers that execute and there may be many SOQL queries being executed in those triggers which is causing this issue.
So first of all make sure that you are not using SOQL queries in a for loop and then try to avoid unnecessary SOQL from your trigger to get rid of this issue.

Let me know if you need more information on this.

Thanks,
Abhishek

All Answers

Abhishek BansalAbhishek Bansal
Hi Rahul,

Salesforce keeps an eye on a complete single context that is being executed by the User at a particular time.
I undertsand your scenario and would like to inform you about the basic reasons for the cause of too many SOQL queries.

May be in your trigger you have written any SOQL in a for loop and if you have not done that then may be while using an update statement on ABC object there are may triggers that execute and there may be many SOQL queries being executed in those triggers which is causing this issue.
So first of all make sure that you are not using SOQL queries in a for loop and then try to avoid unnecessary SOQL from your trigger to get rid of this issue.

Let me know if you need more information on this.

Thanks,
Abhishek
This was selected as the best answer
Himanshu ParasharHimanshu Parashar
Hi Rahul,

Managed package given its own set of governor limits that are separate from the governor limits of other managed packages and unmanaged code in the org they are just separately counted. 

So issue might be somewhere else in your code if you are updating records in loop as Abhishek mentioned.

Thanks,
Himanshu
 
srlawr uksrlawr uk
If you run your (failing) code and examine the logs, you should see the cumulative limits for each namespace (the managed one, and the default one) which I believe are still treated seperatly for the purposes of breaking a limit (ie. you are not added to the managed limit if you interact with their functionality).
 
19:46:29.566|LIMIT_USAGE_FOR_NS|(default)|
Number of SOQL queries: 1 out of 100
Number of query rows: 1 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 1 out of 150
(etc.etc.)

19:46:29.567|LIMIT_USAGE_FOR_NS|ppe|
Number of SOQL queries: 8 out of 100
Number of query rows: 48 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 3 out of 150
(etc.etc.)

Bear in mind if you write code that causes a managed package to "continue" acting on it's own objects during the same transaction, you can cause it to accrue more points towards the crumbly cliff of an exception... even if your code doesn't do much itself (ie. you could write code that just inserts 10 object, totalling 10 DML calls, but that could fire a barrage of triggers on the managed package side in one transaction.