10

It is absolutely possible! We have even built this exact utility where I work. However, I can't just give you the answer, but I will give some hints. SObject methods: get will return the value of the field you are looking for The aforementioned get method can take either a String or a Schema.SObjectField to specify the field you want to pluck. If you ...


9

You don't need to have a return type to get data back to the callee, and sometimes this is more convenient. Here's my version of a "get values from records" implementation: public static void getValuesFromRecords(Object[] result, SObject[] source, SObjectField field) { for(SObject record: source) { result.add(record.get(field)); } } Typical ...


6

I don't believe this is possible currently. There's no methods on Schema.SObjectField of Schema.DescribeFieldResult that link back to the SObjectType that field belongs to.


5

If you want to write a utility that creates records, this function is absolutely necessary in order to be generic at all. Sure, you could also use Type.forName, but that doesn't take nearly as good advantage of strict typing. Simply contrast these test utility styles and imagine which will balloon massively each time you want to support new object types: ...


5

You set the individual fields, such as BillingStreet, BillingCity, BillingState, BillingPostalCode, and BillingCountry (plus the geolocation codes, as well, if you prefer). The address complex field is a convenience field derived from the parts, just as a contact or lead's "Name" field is really a concatenation of the various parts of their name (first, last,...


5

The docs outline the behaviour of the DescribeFieldResult map. See Accessing All Field Describe Results for an sObject There's a note saying: The value type of this map is not a field describe result. Using the describe results would take too many system resources. Instead, it is a map of tokens that you can use to find the appropriate field. After ...


5

Yes, describe maps break the usual case sensitivity rules. They are magical in nature. No, you can't directly replicate the behavior. You could use a wrapper class to store and retrieve only lowercase values using equals and hashCode method overrides, but you cannot construct a native map that's case insensitive.


5

Instead of Account.Type (a specific field), you can use: // Get the describe for the object DescribeSObjectResult objResult = Schema.getGlobalDescribe() .get(selectedObject).getDescribe(); // Get the field dynamically DescribeFieldResult fieldResult = objResult.fields.getMap() .get(...


4

Checkbox Advantages Will never be indeterminate. This is useful for coding, mostly. Can be represented in different ways. You can use 0, 1, true, and false. This reduces import errors, and simplifies report criteria. Is a true Boolean. This means formulas don't need ISPICKVAL to work, so they are simpler to read. This is also true in code. Requires only ...


4

//It provides to get the object fields label. String fieldLabel = fieldMap.get(fieldName).getDescribe().getLabel(); //It provides to get the object fields data type. Schema.DisplayType fielddataType = fieldMap.get(fieldName).getDescribe().getType(); Your code will look like this.. Map<String, Schema.SObjectType> gd = Schema.getGlobalDescribe(); ...


4

The only reasonable method I know of is to use a try-catch block: try { record.put(someField, someValue); } catch(SObjectException e) { // Field could not be written } Unfortunately, this is an expensive construct (~30ms per failed access), so you might want to at least pre-validate that it is !(isCalculated() || isAutoNumber()).


3

You cannot get only editable fields using Schema.getGlobalDescribe(). You need additional check. Map<String, Schema.SObjectField> fields = Schema.getGlobalDescribe().get('Account').getDescribe().fields.getMap(); List<String> editableFields = new List<String>(); for(Schema.SObjectField fieldRef : fields.values()) { Schema....


3

The sample code appears to be using the Partner API. Your example error messages indicate you are using the Enterprise WSDL (com.sforce.soap.enterprise.sobject.SObject). The Partner API is loosely typed versus the Enterprise WSDL which is strongly typed. Because the Partner API is loosely typed you need to set the sObject type (setType) and use a generic ...


3

There's all sorts of dodgy ways to do this, but I find that the easiest is to simply use an "out-parameter," because then you don't even need to worry about casting. It works like this: public static void getValuesByField (Set<Object> results, List<SObject> records, SObjectField field){ for(SObject record: records) { results.add(...


3

SFDC has two forms of ID . The API can return either a case-sensitive or a case-insensitive ID field value. The case-insensitive ID is identical to the 15-character case-sensitive ID with three extra characters appended to indicate the case of each of the original 15 characters. When inserting or updating records, the API accepts either the 15-character ...


3

You can't serialize SObjectField, as the error says, but it's easy to get the value as a String: public string jsondata{get;set;} List<String> fieldschema = new List<String>(); for(Schema.SObjectField sfield : fieldMap.Values()) { fieldschema.add(''+sfield); } jsondata = JSON.serialize(fieldschema);


3

List<Schema.FieldSetMember> is just what Schema.FieldSet.getFields() gives you. You can call getFieldPath() on each field set member to obtain the field's API name, and then convert to a Schema.SObjectField via Schema.SObjectType.My_Object__c.fields.getMap().get(fieldSetMember.getFieldPath()); So given your existing code, you can do something like ...


2

Same as Phil Hawthorn's answer but with a loop and you can just "toString" an SObjectType to get its name, no need for another describe: SObjectType t = ...; DescribeSObjectResult dt = t.getDescribe(); for (SObjectField f : dt.fields.getMap().values()) { DescribeFieldResult df = f.getDescribe(); if (df.getType() == DisplayType.Reference) { ...


2

I think you can do something like this: Schema.DescribeFieldResult f = fieldsMap.get(field).getDescribe(); System.debug(f.getRelationshipName()) for(Schema.SObjectType reference : f.getReferenceTo()) { System.debug(reference.getDescribe().getName()); } See docs here for more info.


2

If I were you, I would just copy the FieldReference class into your org and use it as follows: Opportunity someRecord = [SELECT Account.Owner.Name FROM Opportunity LIMIT 1]; Object owner = FieldReference.build('Account.Owner.Name').getFrom(someRecord); However, if you prefer to roll your own method, it should look something like: public with sharing class ...


2

Here the problem is that temp is a String and you try to assign one String into other. Remember s.getSobject('Owner').get('name') returns object and to convert into String user try to typecast into String that you did. So it is not possible to get the right answer until you use it as a String. Hope it clears you. You can use the below code List<sObject&...


2

Your relatedToType in your template is set to "Opportunity" which means that the binding variable relatedTo will reference the Opportunity record. Then at the following line: <apex:repeat var="oppx" value="{!relatedTo.Opportunity}"> you're basically trying to reference a field called "Opportunity" on the Opportunity record [Opportunity.Opportunity]. ...


2

According to support, this is as designed, although it seems more like an oversight than a design decision to me. In any case, it should be documented. From support: The behavior that we see when we are using List is working as designed. Please find the detailed summary for the same below -- The getDMLFieldName's return type is String[] whereas ...


2

Changing from this: result.put(f, sob.get(f)); to this: result.put(String.valueOf(f), sob.get(f)); works around the problem..


2

Since you are setting the field FirstName__c from within the Managed Package, the managed package will always assume that you are wanting to set the field abc__FirstName__c rather than the unmanaged FirstName__c. I don't know as I'd call this a bug, but it is certainly known behaviour.


2

SObject.put(fieldName, value) This method is an overloaded method. It has two definitions: fieldName is of string type fieldName is of Schema.SObjectField type. The first definition of this method will not work for you but the second definition of this will definitely work for you. Schema.SObjectField field = Schema.sObjectType.<object_api_name>....


2

The question appears to be about the difference between the various newSObject methods, not about the general need for that family of methods. From my reading of the (not entirely clear) documentation the key statement may well be: If the loadDefaults argument is false, this method creates the sObject with field values of null. So this: newSObject(...


2

Your approach is not tenable. There are many scenarios where the lookup name may not match the object type. Your logic for custom lookup fields only even works for standard objects. You should take a more programmatic approach and use describes. Instead of trying to guess the object wholesale, guess the field name and walk the path one step at a time. If ...


2

I would recommend double check the line no 2 Schema.SObjectType leadSchema = schemaMap.get('Tools__Order'); Double check the object name here . Tools__order does not look like proper name for an object . Add a system.debug after line 1 and debug the whole map thats returned from the global describe . For custom object with namespace , it will be ...


2

The reporting engine actually provides some additional fields that do not directly exist in the database. This is some special magic specific to reporting. In this specific case, Amount (converted) is translated into the following SOQL: SELECT convertCurrency(Amount) FROM Opportunity ... Generally speaking, if you can't directly find a given field, it's ...


Only top voted, non community-wiki answers of a minimum length are eligible