0

I have one Trigger and Test Class (which is having the coverage of above 80%) that needs to be moved to Production.

There are already some test classes available in the Production where these test classes will be validated on every changeset deployment.

Problem:

While moving the changeset of this trigger and test class, It is hitting the 101 SOQL Queries on the test classes which are already there in Production. I have already used Test.StartTest() and Test.StopTest() functions for every possible scenarios in my test Class.

Note: I used Test.IsRunningTest() in Trigger to solve this 101 SOQL Exception but at that time, It is not covering 75%.

Is there any way to solve this situation now?

  • 1
    Are you getting the same errors in your source environment? It is possible your new code is actually the cause of these errors. – Adrian Larson Aug 18 '16 at 9:54
  • This is typically caused by looping queries, Adrian is probably correct in that the code itself is the problem. – Dan Jones Aug 18 '16 at 9:58
  • 1
    Another common cause is that you may be introducing a trigger recursion that you have not yet accounted for. – Adrian Larson Aug 18 '16 at 10:12
  • @AdrianLarson, Thanks for the response. Yes I am getting the errors in my source environment only. But the errors with classes names are showing at the time of Validation in Production ChangeSet. It is not regarding the Trigger Recursion. It is because the queries are overflow within the trigger. Basically, the process that trigger is firing has very big process. If one update is happened, It will check for nearly 10 classes including Batches – Subhash Aug 18 '16 at 10:22
  • @Poet, I didn't use any Looping Queries. I just used one DML that is also by taking everything of my need in a LIST and updating through DML operation after For Loop. – Subhash Aug 18 '16 at 10:23
5

It sounds like the unit tests did exactly what they were supposed to in blocking this deployment. It seems like the trigger logic you added pushed the system over the edge. Either it was already overburdened and near the breaking point, or the new logic is too heavy a burden on it's own. If you don't need the data real time, consider moving the logic to run asynchronously, possibly on a schedule like every 15 minutes.

| improve this answer | |
  • Thanks for your reply, I hope i need to change the all coding queries of all the classes and triggers according to the test class coverage... – Subhash Aug 20 '16 at 6:03
1

It is hard to give an abstract response without seeing the code but you can use something like

system.debug('Query Limit is'+ Limits.getQueries());

in multiple places in your code to see which chunk uses more queries that add up. You can also break the transaction by using Asynchronous Apex or reduce your SOQL usage by Bulkifying your code.

| improve this answer | |
  • Thanks for your concern, Debugging Logs is an out of option because, it is saying that "Maximum Debug Limit reached" and I can't put the coding too... Because you may understand how much huge code that it is showing as maximum limit... – Subhash Aug 20 '16 at 6:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.