Find your content:

Search form

You are here

Required Field on VisualForce Triggers "SObject row does not allow errors" message?


I must be missing something here..I have a visualforce page, that enables a user to create a Campaign - I have a pageblock/section with the Campaign Fields, including name, and Name is marked required. I click a button, and if the name field for Campaign is blank, I get this error:

System.FinalException: SObject row does not allow errors

In the logs, the line before my error is a VF Page Message "You Must Enter a Value", but instead of throwing the error back to the user, the next line is:

EXCEPTION_THROWN [EXTERNAL]|System.FinalException: SObject row does not allow errors

And the thing is, if I remove all code in the pagereference call in the controller, and just return null, it still gives the error, but as far as I can tell, I am not writing anything to the database?

Update - apparently, it is this line causing my issue:

newCampaign = (Campaign)Campaign.sObjectType.newSObject(null, true);

if I use the standard way:

newCampaign = new Campaign();

the page works just fine.

Is that expected behavior?

Attribution to: BritishBoyinDC

Possible Suggestion/Solution #1

From reading the details of the feature, and your statement about not performing DML, I'd say this is a possibly a bug. The newSobject method should just instantiate a new Campaign with the default values and default record type given the way you called the method.

Can you post more of the method you're calling when they create the campaign? You're not trying to use addError directly on the instantiated SObject if they forgot Name are you?

Attribution to: drakored

Possible Suggestion/Solution #2

I had the same issue and putting a <apex:pageMessages /> on my VF page helped me figure out the root cause of this error.

Attribution to: Robert Sösemann

Possible Suggestion/Solution #3

I have found a successful work around for this issue that still allows users have the defaulted values while not getting an error for their troubles.

Essentially you create an object that has been set with defaults and one that has not. Then using field describes, go field by field, and copy the values from the defaulted sobject the other that has not been.

Here is the function that I use to get around this particular hurtle:

     * This method will create get the default values for an sobject record bypassing a known issue
     * that can cause an error, "SObject row does not allow errors" on a visualforce page
     * @return The sobject record with the correctly defined default values
    public static SObject getSobjectDefault(String sobjectName) {
        Schema.SObjectType targetSobjType = Schema.getGlobalDescribe().get(sobjectName);
        //Need to have two sobjects, one initialized with default values one without
        SObject sobjDefaultRecord = targetSobjType.newSObject(null, true);
        SObject actualSobjRecord = targetSobjType.newSObject();

        //Need to use the describes to copy the default data into the actual sobject record that Visualforce
        //will use
        Schema.DescribeSObjectResult sobjDescribe = sobjDefaultRecord.getSObjectType().getDescribe();
        Map<String,Schema.SObjectField> fldMap = sobjDescribe.fields.getMap();

        //Going through each field so we can move the data from the default record into actual sobject record
        for (String fld : fldMap.keySet()) {

            //Using object so we do not need to cast the correct type
            Object defVal = sobjDefaultRecord.get(fld);
            Schema.DescribeFieldResult dfr = fldMap.get(fld).getDescribe();

            //Because we are going through every field, need to ensure that we copy fields that are able to be copied. 
            //Specifically ran into a problem with the isDeleted field in particular, which is not writable
            if (defVal != null && dfr.isPermissionable() && dfr.isCreateable()) {
                actualSobjRecord.put(fld, defVal);
        return actualSobjRecord;

Attribution to: Jason Hardy

Possible Suggestion/Solution #4

As mentioned in my comment, it's a bug. I got a response from Salesforce today confirming it.

Here is the bug in the known issues tracker:

As you have deduced it is caused when an object is instantiated using the SObjectType.newSObject method, but only when the useDefaults flag is true. Which without it defeats the purpose of instantiating the Campaign record in that way.

Attribution to: Daniel Blackhall
This content is remixed from stackoverflow or stackexchange. Please visit

My Block Status

My Block Content