You need to sign in to do that
Don't have an account?
JasonRogers
Strange Error: "A duplicate value was specified for field"
Previous to updating to 8.0 we had some code that would update fields on Opportunities. After updating to 8.0 we get this failure (there has been no other change in the code besides the update):
AxisFault: A duplicate value was specified for field 'Consulting_Amount__c' in object 'Opportunity', duplicate value '0.0' prior value '' (prior value could have been set to '' with 'fieldsToNull')
Does anyone have a clue why this would be?
AxisFault: A duplicate value was specified for field 'Consulting_Amount__c' in object 'Opportunity', duplicate value '0.0' prior value '' (prior value could have been set to '' with 'fieldsToNull')
Does anyone have a clue why this would be?
As there's no way for us to tell which one is the one you really mean, we now error out.
Thanks Simon. It was indeed the case that we were setting the value to 0.0 and putting it in the fieldsToNull array at different times. Thanks for your help. I guess I had better poor through the release notes better.
(This is a drive-by comment on my part because I haven't come across this problem yet...)
Why is this a good idea? Why not pick one over the other as the default action instead of error'ing out.
Specifically, getting a value onto the FieldsToNull parameter requires "out of the way" coding to make it happen, whereas dumping an empty string into a field may happen frequently during normal processing.
If your "normal" processing is working with integration data, etc., it's a reasonable model to do your processing, storing values into your fields, and then when you're done and ready to save, you simply set up the FieldToNull array by reviewing the contents of the fields you are interested in, and appending them to FTN if they are null, or empty strings, or zeroes, etc., whatever your processing wants to consider nulls.
In short, why not make the FieldsToNull setting override any value in the field? Sure it's not as "clean", but it's more usable, and probably what we will in general want.
Thanks, Steve.
Any help would be greatly appreciated.
Same error was occuring for me.When i was trying to upsert data from CLI.
i got the solution for it.
This error was coming from me due to that i have made sfdc.insertNulls=true.
Then i change it to sfdc.InsertNulls=false.Then everything was working fine.
So if you are using this settings then change it.
Please reply, it solves the problem or not.
Thanks
Raj
Can you please let me know where I should make these changes... ?
I too get the same error
I'm stumped... Probably something stupid. But, can't quite figure it out.
We are integrating our company data with salesforce account data. I recently noticed that setting the state to "" on non US/CAN address was not working. Upon investigation I found that I needed to explicitly set it to null by using this method. A little more work, but not biggie. However, then I got that exception of duplicate field value. Hmmm... so, I changed the code around thinking this might work.... as you can see I'm either setting it or nulling it. Not both. So, can someone please tell me what I have to do to clear this value???
Example of code:
if (!"USA".equals(company.get("country")) && !"CAN".equals(company.get("country"))) account.setFieldsToNull(new String[] {"BillingState"}); else count.setBillingState(company.get("state"));
ERROR:
SFORCE Exception: Account: An unexpected error has occurred.A duplicate value was specified for field 'BillingState' in object 'Account', duplicate value 'AL' prior value '' (prior value could have been set to '' with 'fieldsToNull')
Thank you in advance!!!
The only time I am reference foo is when I am either setting it (if it should have a value) or if I am using setFieldsToNull. I never do both? So how can it be "listed" twice?
BTW: Thanks for the response.
ughhh.... should I start another post on how to output the xml being submitted? Or is it a quick one liner?
On a side note: I was just talking with a fellow developer and the only thing we could think of is this: For simplicity we always include every fiield we will be interested in when retrieving the SObject using the binding.query(sql). The other thing we do for simplicity is always perform an upsert(). Probably wrong functionally, but that way we have one easy to understand wrapper method that handles all of our needs.
I'm not sure if any of that info helps or not, but I thought I would add as much info as I could think of. Thanks again Simon!
If you r trying to deploy metadata(Object information) from one Org to another, and the fields name are same you get this error.
EX.
Org 1:
RecordType Name: RT1
Record Type Lable: MyRT1
Org2:
RecordType Name: RT1
Record Type Lable: MyRT 1
Now when you try to deploy RT1 from Org1 to Org2.... you get this error. Please check for what object you are getting this error and try to compare the fields from both Org.
Reason:Names have to be unique. In the above case RecordType Name is RT1 in both case..
I think Simon has it... because we are not deploying to more than one org.
I really hate taking over someone else's code. Never know what you're gonna get. LOL Anyway, looks like it will be hard to change things around. However, I have no options do I? I'm now realizing why we have so many performance issues too. That's a lot of junk to be passing back and forth all of the time. I originally thought the API was handling the xml during an update.... ie. the setFoo(String) method would only include that field when it came update time. A quick look at some of the API examples and it's all making sense now.
Thanks again!
This also happens when you import data from CSV file(using msexcel) that has garbage data somewhere in excel sheet. So, in those case, i would recommend copying the data to a new CSV file & try importing again.
Javascript is not case sensitive like salesforce, so result.field_in_question__c is different from result.Field_In_Question__c which is the correct name. So the former is 'value' while the latter is '', but when salesforce tries to update, this is duplicate, since it interprets them as case insensitive.