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
pvandepvande 

System.FinalException: Record is read-only:

I am new to apex triggers and am attempting to write one to populate a field on Project__c.  I amgetting a read only error when I try to edit my custom object Project__c.    Thank you for looking.

Here is my error:  Error: Invalid Data. 
Review all error messages below to correct your data.
Apex trigger UltimateForecast caused an unexpected exception, contact your administrator: UltimateForecast: execution of AfterUpdate caused by: System.FinalException: Record is read-only: Trigger.UltimateForecast: line 12, column 1

 I have highlighted the field that appears at line 12, column 1.  It is a formula field.  Is that the problem?

Here is my trigger:
Trigger UltimateForecast on Project__c ( after insert, after update) {
    For(Project__c p : Trigger.New){
          List<Account> incomingprojinfo = [Select Forecast_Account__c 
                                                                    FROM  Account WHERE Id =:p.Sponsor_Account_Ultimate_Parent__c LIMIT 1];
                                                                     p.Is_Sponsor_Account_Ultimate_Parent__c = incomingprojinfo[0].Forecast_Account__c;
            }                                                        
                                   }
Best Answer chosen by pvande
Amit Chaudhary 8Amit Chaudhary 8
yes remove line 17.
Trigger UltimateForecast on Project__c ( before insert, before update) 
{
	
	Set<String> setStr = new Set<String>();
    For(Project__c p : Trigger.New)
	{
		if(p.Sponsor_Account_Ultimate_Parent__c != null)
		{
			setStr.add(p.Sponsor_Account_Ultimate_Parent__c);
		}
	}
	
	if(setStr.size() > 0 )	
	{	
          Map<Id,Account> mapACC = new Map<Id,Account> ( [Select Forecast_Account__c  FROM  Account WHERE Id in :setStr ] );
																	
			
		For(Project__c p : Trigger.New)
		{
			if(p.Sponsor_Account_Ultimate_Parent__c != null && mapACC.containsKey(p.Sponsor_Account_Ultimate_Parent__c) )
			{
				p.Is_Sponsor_Account_Ultimate_Parent__c = mapACC.get(p.Sponsor_Account_Ultimate_Parent__c).Forecast_Account__c;
			}
		}
			
	}
	
}
Trigger Best Practices | Sample Trigger Example | Implementing Trigger Framework

1) One Trigger Per Object
A single Apex Trigger is all you need for one particular object. If you develop multiple Triggers for a single object, you have no way of controlling the order of execution if those Triggers can run in the same contexts

2) Logic-less Triggers
If you write methods in your Triggers, those can’t be exposed for test purposes. You also can’t expose logic to be re-used anywhere else in your org.

3) Context-Specific Handler Methods
Create context-specific handler methods in Trigger handlers


4) Bulkify your Code
Bulkifying Apex code refers to the concept of making sure the code properly handles more than one record at a time.

5) Avoid SOQL Queries or DML statements inside FOR Loops
An individual Apex request gets a maximum of 100 SOQL queries before exceeding that governor limit. So if this trigger is invoked by a batch of more than 100 Account records, the governor limit will throw a runtime exception

6) Using Collections, Streamlining Queries, and Efficient For Loops
It is important to use Apex Collections to efficiently query data and store the data in memory. A combination of using collections and streamlining SOQL queries can substantially help writing efficient Apex code and avoid governor limits

7) Querying Large Data Sets
The total number of records that can be returned by SOQL queries in a request is 50,000. If returning a large set of queries causes you to exceed your heap limit, then a SOQL query for loop must be used instead. It can process multiple batches of records through the use of internal calls to query and queryMore

8) Use @future Appropriately
It is critical to write your Apex code to efficiently handle bulk or many records at a time. This is also true for asynchronous Apex methods (those annotated with the @future keyword). The differences between synchronous and asynchronous Apex can be found

9) Avoid Hardcoding IDs
When deploying Apex code between sandbox and production environments, or installing Force.com AppExchange packages, it is essential to avoid hardcoding IDs in the Apex code. By doing so, if the record IDs change between environments, the logic can dynamically identify the proper data to operate against and not fail
 

All Answers

HARSHIL U PARIKHHARSHIL U PARIKH
I would say this must be Before Insert, Before Update trigger.... (Well, I don't know the all requirement so I can be wrong here ;) )

Try using following trigger,
Trigger UltimateForecast on Project__c ( Before insert, Before update) 
{
    For(Project__c p : Trigger.New)
    {
         If(p.Sponsor_Account_Ultimate_Parent__c != null)
         {
           List<Account> incomingprojinfo = [Select Forecast_Account__c FROM  Account WHERE Id =:p.Sponsor_Account_Ultimate_Parent__c LIMIT 1];
           
           If(!incomingprojinfo.IsEmpty())
           {
               p.Is_Sponsor_Account_Ultimate_Parent__c = incomingprojinfo[0].Forecast_Account__c;
           }                                                      
              
         }
       
    }                                                        
}
Hope this helps!
 
Amit Chaudhary 8Amit Chaudhary 8
I found below issue in your code
1) Please update your trigger to before insert and before Update
2) SOQL inside the for loop

Try to update your code like below
Trigger UltimateForecast on Project__c ( before insert, before update) 
{
	
	Set<String> setStr = new Set<String>();
    For(Project__c p : Trigger.New)
	{
		if(p.Sponsor_Account_Ultimate_Parent__c != null)
		{
			setStr.add(p.Sponsor_Account_Ultimate_Parent__c);
		}
	}
	
	if(setStr.size() > 0 )	
	{	
          Map<Id,Account> mapACC = new Map<Id,Account> ( [Select Forecast_Account__c  FROM  Account WHERE Id in :setStr ] );
																	
			p.Is_Sponsor_Account_Ultimate_Parent__c = incomingprojinfo[0].Forecast_Account__c;
			
		For(Project__c p : Trigger.New)
		{
			if(p.Sponsor_Account_Ultimate_Parent__c != null && mapACC.containsKey(p.Sponsor_Account_Ultimate_Parent__c) )
			{
				p.Is_Sponsor_Account_Ultimate_Parent__c = mapACC.get(p.Sponsor_Account_Ultimate_Parent__c).Forecast_Account__c;
			}
		}
			
	}
	
}

Let us know if this will help you
 
HARSHIL U PARIKHHARSHIL U PARIKH
I would definitely aggree with Amit here about SOQL inside the for loop and his trigger handels it better ;) :)
But I think we don't need the line 17 I guess..

By the way, thank you Amit since I can use this technique in some of my other trigger in my org!
Amit Chaudhary 8Amit Chaudhary 8
yes remove line 17.
Trigger UltimateForecast on Project__c ( before insert, before update) 
{
	
	Set<String> setStr = new Set<String>();
    For(Project__c p : Trigger.New)
	{
		if(p.Sponsor_Account_Ultimate_Parent__c != null)
		{
			setStr.add(p.Sponsor_Account_Ultimate_Parent__c);
		}
	}
	
	if(setStr.size() > 0 )	
	{	
          Map<Id,Account> mapACC = new Map<Id,Account> ( [Select Forecast_Account__c  FROM  Account WHERE Id in :setStr ] );
																	
			
		For(Project__c p : Trigger.New)
		{
			if(p.Sponsor_Account_Ultimate_Parent__c != null && mapACC.containsKey(p.Sponsor_Account_Ultimate_Parent__c) )
			{
				p.Is_Sponsor_Account_Ultimate_Parent__c = mapACC.get(p.Sponsor_Account_Ultimate_Parent__c).Forecast_Account__c;
			}
		}
			
	}
	
}
Trigger Best Practices | Sample Trigger Example | Implementing Trigger Framework

1) One Trigger Per Object
A single Apex Trigger is all you need for one particular object. If you develop multiple Triggers for a single object, you have no way of controlling the order of execution if those Triggers can run in the same contexts

2) Logic-less Triggers
If you write methods in your Triggers, those can’t be exposed for test purposes. You also can’t expose logic to be re-used anywhere else in your org.

3) Context-Specific Handler Methods
Create context-specific handler methods in Trigger handlers


4) Bulkify your Code
Bulkifying Apex code refers to the concept of making sure the code properly handles more than one record at a time.

5) Avoid SOQL Queries or DML statements inside FOR Loops
An individual Apex request gets a maximum of 100 SOQL queries before exceeding that governor limit. So if this trigger is invoked by a batch of more than 100 Account records, the governor limit will throw a runtime exception

6) Using Collections, Streamlining Queries, and Efficient For Loops
It is important to use Apex Collections to efficiently query data and store the data in memory. A combination of using collections and streamlining SOQL queries can substantially help writing efficient Apex code and avoid governor limits

7) Querying Large Data Sets
The total number of records that can be returned by SOQL queries in a request is 50,000. If returning a large set of queries causes you to exceed your heap limit, then a SOQL query for loop must be used instead. It can process multiple batches of records through the use of internal calls to query and queryMore

8) Use @future Appropriately
It is critical to write your Apex code to efficiently handle bulk or many records at a time. This is also true for asynchronous Apex methods (those annotated with the @future keyword). The differences between synchronous and asynchronous Apex can be found

9) Avoid Hardcoding IDs
When deploying Apex code between sandbox and production environments, or installing Force.com AppExchange packages, it is essential to avoid hardcoding IDs in the Apex code. By doing so, if the record IDs change between environments, the logic can dynamically identify the proper data to operate against and not fail
 
This was selected as the best answer