function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
devisfundevisfun 

Getting "Too many query rows: 50001" error on trigger... but query has limit

Hello,

 

I have the following query in a trigger which gathers used serial numbers for a product; this will guarantee that the serial numbers generated in this trigger will be unique:

 

Serial_Number__c[] lstSNInspReg = [select Id, Serial_Number__c from Serial_Number__c where Available_for_use__c = false limit 45000];

 

Yet when I run a test class which runs this line, I get the indicated error.  I'm not sure how this query is returning more than 50,000 rows if it's limited to 45,000.

 

Any ideas?

 

Thanks!

Sean TanSean Tan

The query isn't returning more than 45k records. It's the fact that in your Apex context more than a total of 50,000 rows have been returned. So for example lets say you have two queries that have run in your Apex context:

 

select Id from Account where Name = 'blah' - returns 100 records

select Id from Contact where Account in List above - returns 1000 records

 

The total # of rows returned in the above Apex context is 1100 records.

 

devisfundevisfun

Hi Sean,

 

Thank you for replying.

 

I do in fact have another query in the trigger, which has a a limit of 9500 (since this query is a list that will be updated, I'm limited to only 10k rows).  However, our org data doesn't return all 45k lines in the culprit query... it only returns a bit over 8k.  At best I'm looking at well under 20k lines.

 

My test class is only returning a few lines since they're all limited to 1 row.

 

So I don't think I'm returning more than 50k rows.

 

Of course, this is only happening on live; the test org isn't complaining of this issue.

 

Could it be something else?

Sean TanSean Tan

The only thing I can recommend (with the limited scope of what I know of your code) is to look at the debug logs. After each of your queries that are running in the transaction you can add a System.debug and print the Limits.getQueryRows value to get the # of records returned up to that point.

 

From there you can probably see whats happening and why the number of rows spikes.

 

Bhawani SharmaBhawani Sharma
You can see Limit logs in debug log
Number of SOQL query used
Number of SOQL query rows retrieved
devisfundevisfun

So here's what I think is going on:

 

There are three test methods within a test class which test this trigger.  Three are needed to test the trigger.  Although they are separate methods, the number of query rows is not reset.  I thought once the test method is finished the limits are all reset... perhaps not.  I'm pretty sure if I take one of the test methods and put it into another class this should resolve itself.

 

Thanks for the input!

Sean TanSean Tan

As far as I know you're correct about your comment on limits resetting for each test method. So if I have my class like this:

 

@isTest
private class MyTestClass
{
	private static testMethod void test_One()
	{
	}
	
	private static testMethod void test_Two()
	{
	}
	
	private static testMethod void test_Three()
	{
	}
}

 Each of the test methods will have their own governor limit context.

 

After you try out your change can you post the results? I'm curious to see if that's really what's happening as this would be the first time I've seen it.

devisfundevisfun

Actually we are right:  a new method does reset the limits.  I'm now looking more closely at this and am noticing that there are three instances of this trigger firing from one test method, and each time the queries are run.  My trigger is on an insert and update, and while my test method strictly does inserts I must be updating them elsewhere so the update trigger is being called twice.  That's why I thought there aggregating... I have three methods and I saw the debug lines three times.  Of course, there were more of them (nine in total) but only saw the first three and stopped looking since I thought there was a problem with the test methods not resetting their limits.

 

I'm good for now.  Thanks again!