Search Results

You can access SObject fields using Strings (as well as using SObjectField tokens): see the get and put methods listed in the sObject Class documentation. … But if you want to do that it is possible via this map for any SObject: Map<String, SObjectField> m = SObjectType.Account.fields.getMap(); PS The way that you access fields using strings (or SObjectField …

To access the related lists you first need to cast the generic SObject type to the correct type: List<Contact> contactList = new List<Contact>(); for (SObject sob : query_result) { Contact c = (Contact … methods: for (SObject sob : query_result) { List<SObject> caseList = sob.getSObjects('Cases'); List<SObject> taskList = sob.getSObjects('Tasks'); // Do whatever you want here with the lists …

You can use this dynamic access technique (all SObjects support map-like methods): for (Sobject record : kbList) { String stringField = (String) record.get('StringFieldApiName'); ... } to avoid … If you do need type-specific logic, the relatively new switch is a good way to do that: for (Sobject record : kbList) { switch on record { when Faq__kav f { // f is a reference …

Assigning the id in the constructor of the SObject does work. …

You could vote for this Provide an additional addError method on SObject that accepts a field name idea, but as it has got nowhere in the last 5 years there is no reason to expect any progress in the next …

Likely cause is the specific behaviour of the deserialization methods. Try JSON.deserializeUntyped instead: Task taskRecordFromString = (Task) JSON.deserializeUntyped(jsonString); Your JSON.deseriali …

Equality and the hash code value are based on all the properties of the SObject which makes sense. … There is an SObject-specific nasty case: if you put SObjects in a set before they are persisted, persisting them will set an Id in the SObjects and your set will be broken in any following logic. …

Your local variable: decimal smallQtyPenalty = 1; is hiding the class name smallQtyPenalty. (That is the compiler has discarded its idea that smallQtyPenalty is a class name in favour of thinking t …

I suggest that you add a field to the SObject called something like "ApplicableOrganizationId" and then route all access through a method that looks something like this: public String getCallbackUrl() …

If the JSON string has names that exactly match the SObject field names then you can use code like this: var s = '{"Field1__c" : "Hello", "Field2__c": "World"}'; var o = JSON.parse(s); var sob = new sforce.SObject …

Converting the field names into a single string risks matching a field called e.g. "Name" with some other field such as "OtherName__c". So one piece of advice is to keep the fields separate: // Field …

I suggest building and serializing nested maps for this: Map<String, Object> m = new Map<String, Object>(); for (options__C opt:options) { m.put(opt.Name__c, new Map<String, Boolean>{ …

The apex:inputField value u.contact must correspond to an SObject field. That is typically done by u being a reference to an SObject and contact being an SObject field name. … For your example, that SObject field would be lookup field to Contact. …

.); call at the end: Id id = 'xxxxxxxxxxxxxxx'; SObjectType t = id.getSObjectType(); SObject[] records = Database.query('select Id, Name from ' + t + ' where Id = :id'); System.debug(JSON.serializePretty …

DescribeSObjectResult d = Account.SObjectType.getDescribe(); List<String> fields = new List<String>(d.fields.getMap().keySet()); String soql = 'select ' + String.join(fields, ', ') + ' from Account where Id = :id'; SObject …