Developer: “Compiled formula is too big to execute (xxxxx characters). Maximum size is 5,000 characters,”

If you have ever hit this error “Compiled formula is too big to execute (xxxxx characters). Maximum size is 5,000 characters,” then it means that is it time to revisit the implemented formula
and refine it.

This does not in the literal sense mean that you have 5000 chars in your formula, it just means that there are either: too many nested IF's, formulas referring other formulas etc.

Following are some of the approaches that you can take to resolve this error:

• Use CASE Instead Of Nested IFs--Implementing this has usually worked for me
• Use Workflow Field Update--the formula field here has a larger capacity and hence might

       accomodate your formula but be careful to ensure that this update is executed only as needed

• Use an Apex Trigger

Thanks

Administrator: No Portal available error....

I was trying to setup Partner Portal on my local and getting this error. Basically, you need to create

• Account and Enable as Partner Account.
• Create a Contact and associate it to the Partner Account.
• Create a User record and associate the Contact record to the Partner User.

From Setup---Portal Settings; Identify the right profile that needs to be associated to the Portal and then associate this Profile to the User record.

You should now be able to login to Partner Portal on your local.

Developer: Scheduleable class has jobs pending or in progress...

If you run into this error while making changes to an APEX class "Scheduleable class has jobs pending or in progress..." then it means that there are scheduled jobs thru the UI or thru the System.Schedule method.

Firstly, clear the existing job by running the following code:

List<CronTrigger> listCronTrigger = [select Id, CronExpression, EndTime, NextFireTime, OwnerId,
        PreviousFireTime, StartTime, State, TimesTriggered, TimeZoneSidKey from CronTrigger
        where State = 'Waiting' or State='Running'];
       
System.debug('No of jobs: '+listCronTrigger.size());

If (listCronTrigger.size() > 0)
{
    for (Integer i = 0; i < listCronTrigger.size(); i++)
    {
        System.abortJob(listCronTrigger[i].Id);
        System.debug('Job details ::'+String.valueOf(listCronTrigger[i]));
    }
}

Now, try to save your APEX class and it should go thru successfully.

Developer:Error: Compile Error: Loop variable must be of type SObject

Our environment had implemented seperation of concerns and so the logic for triggers was in helper classes.

When trying to access trigger.new in helper classes; the context is not available automatically, you have to explicitly pass these attributes to your helper classes.

So, ClassName.MethodName(Trigger.New) should be used to call your class and explicitly pass the trigger collections.

Developer: System.Exception: SObject row does not allow errors

"SObject row does not allow .."  error was encountered while doing validation in a BeforeDelete trigger.

Solution

Very often; error in triggers are handled the traditional way that object.adderror('ErrorMessage').

trigger ClosedOpportunityPreventDeletion on Opportunity (before delete) {

if (system.Trigger.isDelete){

Opportunity[] Opps = [select id, (select id, Opportunity__c from PCFS__r) from Opportunity where id in :Trigger.oldMap.keySet()];

for (Opportunity o : Opps){

if(o.PCFS__r.size()>0){

o.adderror('You cannot delete this Opportunity as it has one or more Customer Forms associated with it');

}

}

}

} 

However, when using adderror in a before delete it is important to maintain Context, the error can only be applied to those records that are in context.

Use the OldMap to get the actual record and apply the adderror message against that record. That should solve the problem. See sample below.

  Opportunity actualRecord = Trigger.oldMap.get(o.Id);

actualRecord.adderror('You cannot delete this O

Developer: Loader/Trigger Errors....Too many batch retries in the presence of Apex triggers and partial failures.”

Too many batch retries in the presence of Apex triggers and partial failures. Usually you get this while loading data thru data loader. However, instead of the standard sensible error messages you get something like "Too many...."

If you ever run into this error; turn on the logs, identify the trigger and straight go to your trigger and review the code.

Most likely there is a bulk DML operation happening in the trigger which has AllorNone option set to True.

Review the following Salesforce document which explains in details the process:
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_bulk_exceptions.htm

Review the data is being loaded and try to load with smaller sets and see if the problem is locatable.
Fix the problem and then load in bulk.

Developer: Too many SOQL queries....

When you hit this error; standard best practice will ask you to review the following:

1. Since Apex runs on a Multitenant structure, Apex runtime engine strictly enforces limits to ensure code doesn't monopolize shared resources. Learn about the Governors Limit.
2. Avoid SOQL queries that are inside FOR loop.
3. Check out the Salesforce Developer Blog where you can find Best Practices for Triggers.
4. Review best practices for Trigger and Bulk requests on our Force.com Apex Code Developer's Guide.
5. Be sure you're following the key coding principals for Apex Code in our Developer's Guide.


Sometimes the answer is not that obvious that you review a piece of code and you find the solution.

Here's my list of steps:

Review your WF/Process Builder rules; many times Admins write basic updates on the same entity causing continous firing of Before/After triggers. Try to move them to code.

Review the WF rules and move them to formulas; check for ISCHANGED so that the rules are not fired perpetually.

If this too doesn't solve your issues; turn the debug logs on. Look for SQL_EXECUTE_BEGIN.  Salesforce does a good job providing the query num that is being fired. Try to observe the pattern; atleast one query or process is being fired repeatedly. Work on that process or query; typically making it @future has helped solve the issue. However, if you are in an environment where the code is not being written by you or jumps from class to class that keeping track can become challenging and confusing use the log route to zero in on your problem.