function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Uwe HeimUwe Heim 

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:
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...


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.

Uwe HeimUwe Heim
I was unlucky with my case 10508340 about this issue. Chaten Raghav from Salseforce was very quick to close it as "out ouf scope". I am trying now to get it re-opened with case 10509659. Because I think Salesforce should care about qualified bug-reports.

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?
Currently am able to solve the issue by removing Address fields in the method.
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.

Uwe HeimUwe Heim
Hi nbk
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
    ) {

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!
Uwe HeimUwe Heim
Such a pitty, second time sfdc support rejected my bug-report. Seems that I can't provide any of my reproducable test-cases, so giving up. For myself it's done, I have a usable workaround - but for others I could be hard.
 Is possible for you to reproduce the scenario in your personel development orgs. If yes SF team may consider the issue!