I have tried all the fixes listed:

Unable to read sObject error when saving Record From a Lightning Component's Controller

Lightning Components in Visualforce - Unable to read sobject

Unable to read SObject error in Lightning Component when record has been queried from the database

  1. set sobjectType = 'NS__ObjectName__c'
  2. set attributes = null

etc, etc, etc.

Anyone have any other ideas?

Some known facts:

  1. The sObject is defined on the parent as:

     <aura:attribute name="theObject" type="NS__APINAME__c"
                description="The sObject we will be working with"/>

(actual names removed to protect the innocent, it is a custom object from a managed package)

  1. the sObject is retrieved from the apex controller with a lookup relationship populated with the ID of the appropriate record. It is instantiated in the apex controller as follows

     return New NS__APINAME__C(LOOKUPFIELD__C = theId);
  2. This sObject is passed into a child component as an attribute in the child component as such:

     <aura:attribute name="theObject" access="public" type="NS__APINAME__C" required="true"/>

The controller on the child component


    upsertObject : function(component, event, helper) {
        var action = component.get("c.upsertTheObject");
        var o = component.get("v.theObject");


        o.sobjectType = 'NS__APINAME__C';
        o.attributes = null;

            "obj": o //JSON.stringify(o)
        action.setCallback(this, function(response) {
            var state = response.getState();
            if(state == "SUCCESS" && component.isValid()){
                console.log("success") ;

                console.log("failed  ::: " + response.getError()[0].message); 



  1. The method in the apex controller is set to a concrete sObject as the parameter

The only way I have been able to get this to work is by JSON.stringify.

Any one have any other ideas?

Apex method to get sObjectinstance

public static NS__NAME__c getObjectInstance(String lookupId) {
    return New NS_NAME__c(
            Name = 'Test',
            NS__LOOKUP__c = lookupId

Save method

public static NS__NAME__c upsertTheObject(NS__NAME__c obj) {
    //upsert theOrder;
    return obj;

SoapBox I am not sure if it is the mindset coming from Apex/VF or not, but the most basic, simple, things in Lightning have been buggy, not working, difficult to implement, code bloat, etc. So far I am not impressed. I hope that the complex stuff is easier and offsets the steep curve with the basics. I mean cmon, I have to roll my own input for an sObject Picklist, code cannot be shared, loading does not work, can't save an sObject, can get something to eat, but only if x, y, and z are done, but you absolutely cannot do it if e or j is done first, e and j must be done last, then z, then you can eat. Oh my

And to top it off its 1 degree outside and I do not have any hats anymore...

I DO however love the automatic re rendering of the elements and updating of the values etc so far. that part is much easier End soapbox


I just found out that unless you define the attribute with ALL fields you will be using or Query for them, no matter what you do in your controller the values will NEVER be set or passed to the apex controller. What a PITA. If I have an input that sets "{!v.theObject.Name}" it should set the name of the dang object. But I guess since it is JS Name will not be defined unless I define it so i guess I get it...

  • I'll second that. It's been a tough sell to start learning it, even with the brilliant people they have working on it. (Thanks Doug!)
    – Adrian Larson
    Commented Jan 10, 2017 at 0:52
  • 1
    Yea, honestly it seems the complex stuff is much easier. Its just the stuff you think should be the most basic are sooooo difficult. I could have also picked an easier project to start learning on but a simple entry form that can be used in a popup on standard page layout as well as a Lightning Page element has taken 1 VF Page, 1 App, 3 components, 3 controllers, 2 helpers, and 2 css. The helpers and css are ALL duplicative. And All I have got is a billing address entry form lol.
    – Eric
    Commented Jan 10, 2017 at 0:56
  • I was not around for the start of VF and I bet the growing pains were similar....
    – Eric
    Commented Jan 10, 2017 at 0:57
  • 1
    Just curious... did you make sure that all references to the API name are cAsE-sEnSiTiVe? Unlike Apex, Lightning is incredibly ... obsessive-compulsive regarding that.
    – sfdcfox
    Commented Jan 10, 2017 at 1:30
  • 1
    @Praveen - Yup see my answer below. It worked for first save but subsequent returned the same error. Only JSON.stringify() seems to work
    – Eric
    Commented Jan 10, 2017 at 7:28

1 Answer 1


UPDATE - Seems the below still does not work

If I do the below, it sends to server the first time, but does not get the appropriate value back (setting the attribute using the returnValue)so the fields do not update and a subsequent save return the same error. Though I had it but nope. Back to JSON.stringify

Ok. I figured it out.......

Seems the way you set the attribute makes all the difference

When I do this everything works correctly, Including saving of the fields that you do not specifically set.....

<aura:attribute name="theObject" type="NS__APINAME__c" 
     default="{'sobjectType' : 'NS__NAME__c'}" 
     description="The sObject we will be working with"

Basically if you do not define a default and use an apex controller method to return a new instance of the sObject, it WILL NOT work

  • you could have just set the { attributes: { type: "some sobject type" }} in your object before passing it to the back end, it would automatically see it as an SObject with those values set after deserializing it to SObject.class
    – Ronnie
    Commented Apr 3, 2020 at 21:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .