Apex Code Development You need to sign in to do that
Don't have an account?
Bug in Spring'14: Schema.SObjectType.Account.fields.getMap() SOMETIMES(!) get invalid field ShippingAddress
Hi all,
there is strange a and serious bug in spring 14: sometimes (RANDOMLY!) Schema.SObjectType.Account.fields.getMap() get bad results.
It returns beside the 40 standard fields also these 3 problematic fields:
BillingAddress ADDRESS
ShippingAddress ADDRESS
LastViewedDate DATETIME
For the first two we can find something here: https://developer.salesforce.com/forums/?id=906F00000009EPhIAM
So they are "compounded address" fields and should NOT be available in apex. Very good!
But then Schema.SObjectType.Account.fields.getMap() should under NO circumstance return them in APEX.
What do you think?
Worst thing is, that it happens randomly. So Salesforce feels a bit like gambling or remind you of Heisenberg these days...
Uwe
there is strange a and serious bug in spring 14: sometimes (RANDOMLY!) Schema.SObjectType.Account.fields.getMap() get bad results.
It returns beside the 40 standard fields also these 3 problematic fields:
BillingAddress ADDRESS
ShippingAddress ADDRESS
LastViewedDate DATETIME
For the first two we can find something here: https://developer.salesforce.com/forums/?id=906F00000009EPhIAM
So they are "compounded address" fields and should NOT be available in apex. Very good!
But then Schema.SObjectType.Account.fields.getMap() should under NO circumstance return them in APEX.
What do you think?
Worst thing is, that it happens randomly. So Salesforce feels a bit like gambling or remind you of Heisenberg these days...
Uwe
I encountered similar issue (ystem.TypeException: Data type not supported) with Address data type fields in spring 14 - API version 30.0. Seems to be platform level issue and raised a case to salesforce.
more details about the similar issue is below.
https://developer.salesforce.com/forums/ForumsMain?id=906F0000000AHVtIAO
I have 2 expectations:
A) Schema.SObjectType.Account.fields.getMap() should return predictable always the same number of fields. No dice-roll.
B) Schema.SObjectType.Account.fields.getMap() should only return usable and valid fields and NOT stuff of type ADDRESS (at least in APEX context, where it is not supported)
@nbk: what's your status with your case?
Map<String,Schema.SObjectField> M = r.fields.getMap();
Map<String,DisplayType> fieldMap = new Map<String,DisplayType>();
Map<String , Base_Enum_CVMOpearatorsType> fieldWithOperator = new Map<String , Base_Enum_CVMOpearatorsType>() ;
Set<String> existingFieldNamesList = M.keySet();
existingFieldNamesList.remove('otheraddress'); //added this statement to overcome the issue
existingFieldNamesList.remove('mailingaddress');//added this statement to overcome the issue
Case no:10459520 - currently the case is open and I requested to reproduce the issue in their orgs and waiting for reply!
What is the API version you are using in the class, if it is 30.0, change the version to 29.0 and verify.
Can u clarifiy below question:
are you using 'ShippingAddress' field in the vfp, if yes please use the lowercase 'shippingaddress'. I found that the field is accepting lowercase in my scenario.
also found a way and my workaround (in a little bit different scenario) looks like this
...
if( true
&& xsf.soResult.getType()+'' != 'ADDRESS' // random bugs in Spring14
&& fieldName != 'lastvieweddate' // random bugs in Spring14
) {
xso.fields.put(xsf.name,xsf);
}
...
Yes, using lowercase is the right approach.
And I am way back in Version 27 (did not changed it in the XML ever after creation)
So this v30 Bug also impacts classes unsing older API version.
For APEX I think this is a sideeffect from providing extra fields for the API and at the same time suppressing them in APEX. Unfortunately this suppression is like playing dice. I got a scenario at one of our clients Org in a trigger which has a failure rate of less than 5% - was a hell to find out the reason. In a different scenario at our PM-app it fails in 90% - this was easier to track. So I got several places to reproduce. Important is: context-sensitive and random!
Is possible for you to reproduce the scenario in your personel development orgs. If yes SF team may consider the issue!