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

Too many script statements: Error is faced during data upload



I have written trigger which does some functionality upon inserting the records.When I am trying to load the data the trigger executes and giving me the error Too many script statements: 20001.


None of theSOQL queries are inside the for loop.I have used collections like list and map.


Can anyone please help me how  can I resolve this issue.



Srilakshmi B


Too many script statements is different to SOQL queries etc.  It means that your code has executed 20001 lines of apex without carrying out DML/SOQL type statements.  Thus as far as the platform is concerned, there's a good chance you are in an infinite loop or similar.




Too many script statements could indicate you are running a lot of loops, or one loop a really long time (like maybe infinite?). If you can't find an infinite loop, you might try throwing in some system.debug statements that check how many script statements there have been so far.


Ideally, you would find that there's one error that kept a loop from exiting. Triggers can do this if they end up calling themselves. For example, a Trigger on Task that creates another Task will then fire itself and create another Task, unless you are careful to avoid this in your code.


Good luck,



I have a managed package in my instance.. I have created a trigger in my sandbox instance.. But When I run the test classes it is showing too many scriot statements error.. Here is my code: 

trigger dateConvert on CnP__CnP_Transaction__c (before insert) { 


  c.CnP__bSource__c = Integer.valueOf(c.CnP__bSource__c); 

  if(c.CnP__bSource__c == 2){

          c.CnP__TotalCharged__c  = c.CnP__Amount__c;  

          c.CnP__TotalDue__c = c.CnP__Amount__c;  

          c.CnP__Organization_Name__c = c.CnP__Last_Name__c;     

  String delimslash = '/'; 

          String[] DDate;  

          Datetime myDate; 

          String tdate = c.Dummy_Field__c; 


          String[] splitdate = tdate.split(' ');   

          DDate = splitdate.get(0).split('/');   

          String TTime = splitdate.get(1);  

         String   month = DDate.get(0);   

         String   day = DDate.get(1);  

         String   year = DDate.get(2);    

         String   hour = TTime.split(':').get(0);  

         String   minute = TTime.split(':').get(1);  

         String   second = '00';

    myDate = datetime.newInstance(integer.ValueOf(year),integer.ValueOf(month), integer.ValueOf(day),integer.ValueOf(hour), integer.ValueOf(minute), integer.ValueOf(second));

        c.CnP__TransactionDate__c = myDate;  

    c.CnP__TransactionTimeZone__c = myDate;






That doesn't look like it should cause a problem to me, even if you have 200 records in the trigger there aren't that many script statements per record.  Are there any other triggers firing that would cause the script statements to stack up?




There is another trigger on the same object and the same condition that bSource == 2.


But I cannot change the trigger.. because it is coming from a managed package..


I need to do it from here only..


Is there any way possible?






Unfortunately you need to reduce the number of statements executed, but presumably you need the statements to give the behaviour you require.  I don't think you have many options here unfortunately, unless you can maybe push some of the date parsing out to workflow field updates.


I'm having a similar issue - I have a VF page that extract DB records and writes them to a CSV file, and I get a  'Too many script statements' when the requested data range is too big.


While I need to optimise the code, I'm looking for a way to capture the error nicely


Wrapping my code with a try catch doesn't work as the code already stopped executing, so I wonder anyone has a suggestion? should I monitor the number of code statments in the loop and abort when getting too close??


I've ended up doing that in the past when the number of script statements per record were unpredictable.


I used the Limits.getScriptStatements() and Limits.getLimitScriptStatements(), to handle future limit increases. I then bailed when I got within about 5% of the limit, AFAIR.