2

I'm using the Salesforce API via a web service in a .NET solution. I can successfully add an entity to Salesforce, and all of the cost related information is successfully added. When I try to do the same thing for a different entity, some of the data doesn't get added. The data is being correctly set on the .NET object that represents the entity, but the difference is that for the entity that's not fully updating, the corresponding property '...FieldSpecified' is 'false' for the fields that fail to update, so I'm sure this is the problem:

i.e. for My_Entity__c, the property

cost__cFieldSpecified = false

However the actual value of cost__c is correctly set, and is in the correct format (e.g it's correctly set for My_Entity__c as 90.5)

What is causing the FieldSpecified to be set to false, and how do I fix it?

1

The short answer is you need to set the x__cFieldSpecified property to true if you want the current property value sent back to Salesforce.

It's related to elements like the following in the WSDL:

<complexType name="My_Entity__c">
    <complexContent>
        <extension base="ens:sObject">
            <sequence>
                <element name="cost__c" nillable="true" minOccurs="0" type="xsd:double"/>
                <!-- ... -->
            </sequence>
        </extension>
   </complexContent>
</complexType>

So cost__c is nillable, but more importantly it has minOccurs="0". How do you define something that could be both null and unspecified at the same time. The answer in this case is to have an additional FieldSpecified boolean property that indicates if the value should be passed back to Salesforce. That way you can still set the property for the field value to null and submit that to Salesforce.

See also:

| improve this answer | |
  • Thanks Daniel. There are 2 separate entities I'm updating. For the 1st one, when a valid value is supplied for the field, the corresponding '...FieldSpecified' value seems to automatically be set to 'true' - I don't need to explicitly specify it. For the entity that this isn't happening with, I can set those fields to true manually, but I don't understand why I need to do this with the 2nd entity and not the 1st. Also I'm concerned that this could risk errors if I'm always assuming that a value has been correctly specified. Is there a way to ensure that '..FieldSpecified' is automatically set? – Chris Halcrow Jun 28 '17 at 23:15
  • For the entity that works, the wsdl entities for the properties where ...FieldSpecified gets automagically set to '"true" are - nillable="true" minOccurs="0" – Chris Halcrow Jun 28 '17 at 23:20
  • 1
    What does the WSDL element look like for the entity that doesn't work? You might find the generated C# properties are automatically setting the corresponding FieldSpecified property in the set implementation. – Daniel Ballinger Jun 28 '17 at 23:37
  • The WSDL element is the same for the entity that doesn't work. For the entity that works and the one that doesn't, they both use the same generic 'upsert' method of the SforceService class, so I don't see how it could be a difference in the underlying implementation. Also that part of things is essentially black-boxed, so I'm unsure what I can do to ensure that the FieldSpecified gets set automatically. Maybe I just need to set the properties manually, although I'm keen to understand what's occurring and to be able to share that here – Chris Halcrow Jun 29 '17 at 0:46
  • 1
    Doh! There's an intermediary 'set' routine that sets the values for the 1st entity when a unit test is run, which is the way I was testing that entity. It looks like setting those ...FieldSpecified properties manually is always required. Thanks Daniel, I'll award you the answer :) – Chris Halcrow Jun 29 '17 at 1:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.