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
EmsEms 

Bulkify deletion code???

I have 1,042,367 records that need to be deleted in SF (please don't ask how I got here!)

 

I've written code which works perfectly in the sandbox and deletes 10,000 records at a time, but I can't get it to deploy to production... I keep getting the error "System exception: Too many query rows: 1002" when I validate the deployment, although all tests run beautifully in sandbox, even with large amounts of data.

 

Heres the code, it literally deletes listings for a particular MLS if they have a checkbox marked that indicates they should be deleted. (I'm trying to get it to work from a button on the MLS page layout for now, the hope it to set it off in a trigger designated as @future once this is working)

 

 Webservice static integer CleanListingObjectNOW(String db_name)

 

 

    integer cnt = 0;    List<Listing__c> to_del = new List<Listing__C>();

    MLS__c mls = [select id from MLS__C where Database_Name__c =: db_name limit 1];

     for(Integer x=0; x<10;x++){    to_del = new List<Listing__c>([select ID from Listing__c where MLS__C =: mls.id AND Delete_Row__c = true limit 1000]);

    integer sz = to_del.size();

    cnt += sz;

     if (sz > 0)

         delete to_del;

     else

           break;

    to_del.clear();

    }

 

return cnt;

}

 

Any ideas why this would hit governor limits in enterprise production environment but not in our sandbox???

 

THanks,

EMily

 

HarmpieHarmpie
If you surround the actual testcode with startTest() & stopTest(), and test in bulk, you will hit the limits too
EmsEms

Thanks for the starttest function - it helped me debug the rest of the issue.  I actually reverted to a less sophisticated way of doing this - I manually deleted all the records using the data loader, then put my trigger in place which calls an Apex class that executes the deletion in an @future function.

 

The code I have in place won't delete 10,000 records either, but by hand cleaning them the first time I won't create nearly that many on any given day (the trigger gets called nightly by an update process outside of SF) so it will work.

 

Frustrating that I couldn't get this to work the "right" way, but it is working :)  BTW I hear that SF will be including the ability to schedule calls to Apex (mimicking batch processing) in an upcoming release.

HarmpieHarmpie
Keep in mind that asynchronous apex (@future) is still in developer preview. Can probably be activated for you though.