Apex Code Development You need to sign in to do that
Don't have an account?
Gunnar WSDL vs Describe vs OnScreen
BACKGROUND
As you know, there is no ‘SELECT *’ with Apex. You have to specify every field.
When you do a clone, you have to select all the fields.
If someone adds a field after you write the ‘clone’ program, you have to update the clone program with the field changes. PITA and not reliable.
OR
Another way is to use the ‘Describe’, get a list of fields, and assemble the SOQL statement.
That is what I did.
TESTING
As I was testing the program that creates the dynamic SOQL, I let it run, and grabbed the SOQL from the Developer Console. (system.debug).
I then pasted this into the SOQL window in Developer Console.
AND THE PROBLEM IS…
Fields that show in the ‘Account’ (Setup | Customize |Accounts | Fields), these same fields are in the ‘Describe’. Some are NOT in the WSDL, and will not SELECT when doing a SOQL statement.
That does not sound normal to me. Any ideas???
Thanks in advance.
Just stuck me ..... have your checked the field-level security for these fields ? It may have to do with your profile not having access to these fields.
All Answers
Can you give an example of such fields? One thing you can try is - look at the Schema.DescribeFieldResult object for each field, and filter out all fields that have the "isCreatable" attribute set to false.
Also, if you can paste your code here that would be helpful as well.
In accounts, some of the fields that will fail in an SOQL statement are
site, sic, tickersymbol, callpriority
SELECT sic from account
^
ERROR at Row:1:Column:8
No such column 'sic' on entity 'Account'.
Go to the setup | account | fields, and it's there.
Go to the WSDL, it's not.
Can't release the code, it's proprietary. And all it does it get a list of fields using describe. The fields in question ARE in the describe.
This may be escalated to Salesforce...
Definitely something weird going on with these fields.
I tried running a SOQL query like this - select site, sic, tickersymbol from Account
This did not work.
Then, I tried running the below piece of APEX code -
Account a = new Account(); Schema.DescribeSObjectResult r = Account.sObjectType.getDescribe(); Schema.DescribeFieldResult f = Account.Sic.getDescribe(); System.Debug('******************' + f.isFilterable() + '*****************'); System.Debug('******************' + f.isCreateable() + '*****************'); System.Debug('******************' + f.isDeprecatedAndHidden() + '*****************');Then, I again ran the SOQL query from above, and guess what, it worked !!?? Confusing behavior, so you should definitely knock on their door. In the meantime, you might be able to get it working with this hack.
When I ran your code, the method fails - incorrect signature.
Changed 'sic' to 'name' and it works.
So we do have a corruption in Salesforce. This is not resolvable here, it has to go to Salesforce.
Sigh ...
A data corruption is likely, as we have some weird shares going on that are not in the AccountShare table.
But yeah, I'm adding in the 'isCreatable' to the logic.
Thanks!
Just stuck me ..... have your checked the field-level security for these fields ? It may have to do with your profile not having access to these fields.