16

Yes. Collection membership is case sensitive. This applies to Sets: If the set contains String elements, the elements are case-sensitive. Two set elements that differ only by case are considered distinct. and to Maps: Map keys of type String are case-sensitive. Two keys that differ only by the case are considered unique and have corresponding ...


9

<apex:outputPanel rendered="{!contains(UPPER(wrap1.acc.Name),UPPER(wrap2.acc2))}"> Convert all to upper / lower case


7

A shorter version of your code just checks the domain directly: Boolean found = domainNames.contains(email.split('@',2)[1]); There's other ways to do this, too, but this is probably the most straightforward version.


7

Map keys and contains checks (and the same with Set or List) are always case sensitive, with the one exception of describes such as fields.getMap() or Schema.getGlobalDescribe(). However, as soon as you pull the keyset and put it somewhere else, you lose this magical property.


6

From SF docs on Mapss: Map keys of type String are case-sensitive. Two keys that differ only by the case are considered unique and have corresponding distinct Map entries. Subsequently, the Map methods, including put, get, containsKey, and remove treat these keys as distinct. From SF DOcs on Sets If the set contains String elements, the elements ...


5

The List.contains method works exactly like Set.contains. As mentioned in the comments, you need to implement equals and hashCode if you want to use custom types in this sort of comparison. Below is a simple test class to illustrate: @IsTest class Demo { virtual class Foo { Integer x, y; Foo(Integer x, Integer y) { ...


5

Replace = with ==, single equals is for assignment and double for comparison.


4

I think that case sensitivity is a bit of a red herring here. What distinguishes a COO from occurrences of the same letters is the context around it. To pick those up, you need something like a regular expression. Here's a regex which does the job: List<String> strings = new List<String> { 'Coordinator', 'Uncoordinated', ...


4

We usually move the reusable piece of code to a common utility method. You can create a private method that will return the sanitized comment back. private static String getSanitizedComment(String input , String commentPart){ Integer commentStartIndex; //I'm trying to find here the first index of commentPart //if this is the beginning of the ...


4

This is not Apex case sensitivity but a String case sensitivity. You are comparing String values in the Set and thus it will always evaluate based on its equality which is case sensitive. So if your Set contains api_url__c, that's not same as API_URL__C. From documentation: Uniqueness of set elements of user-defined types is determined by the equals and ...


3

If you have control over the type of domainNames, you should consider changing its type to Set<string>. Sets hash their values, so checking whether they contain a particular value takes the same amount of time regardless of the number of elements in the set, compared to a List which must go through each element until it finds one that matches. Set<...


3

As mentioned in Using Custom Types in Map Keys and Sets, you need to override hashCode and equals in order to have Set work correctly with your custom class. For example: public Integer hashCode() { return System.hashCode(id+'♥'+name+'♥'+manager+'♥'+managerid); } public Boolean equals(Object other) { uJson cmp = (uJSON)other; return cmp.id == id &&...


3

Contains method was introduced recently; I guess in version 42.0. To use the it, you would have to upgrade API version of the class. Note: Salesforce recommends to upgrade the API version after every 3 releases. But make sure to check if anything breaks after the upgrade.


3

You can use a Collection of type String to find values using like: String[] cities = 'atl%,por%,bos%'.split(','); Account[] accounts = [select id, billingcity from account where billingcity like :cities]; Otherwise, you'd have to use the far more tedious method of building a query string: select id, billingcity from account where billingcity like 'atl%' ...


2

You can use like this: Set<String> billingCityNames = new Set<String>{'%atl%', 'por%', 'bos%'}; select id, billingcity from account where billingcity like :billingCityNames or you can use: select id, billingcity from account where billingcity like '%atl' OR billingcity like '%por%' OR billingcity like 'bos% Using of bind variable is more ...


2

Use a Map instead: Map<Id, MyObject__c> records = new Map<Id, MyObject__c>(); for (WrapperClass wrapper : wrappers) { if (!records.containsKey(wrapper.getId()) { records.put(wrapper.getId(), new MyObject__c(/*data*/)); } } List<MyObject__c> collectionYouWant = records.values();


2

Use the String.contains() method like so: global class TerminateInboundEmailHandler implements Messaging.InboundEmailHandler { global Messaging.InboundEmailResult handleInboundEmail(Messaging.InboundEmail email, Messaging.InboundEnvelope envelope) { Messaging.InboundEmailResult result = new Messaging.InboundEmailResult(); if ( email....


2

You are assuming that toolsMap.get(g.Id).HelpText__c always returns a value. This may not be true. So whenever it returns null, your current code will fail as you observe. A refactored version of your code should look as below: if(toolsMap.get(g.Id).Status__c == 'Off' || ( toolsMap.get(g.Id).HelpText__c != null &&...


2

In addition to the map/set answers and not specifically Apex but relevant in Apex use of SOQL: Platform Encryption deterministic encryption When you use case-sensitive deterministic encryption, case matters. In reports, list views, and SOQL queries on encrypted fields, the results are case-sensitive. Therefore, a SOQL query against the Contact ...


2

As Phil W mentioned, you cannot filter long text fields in SOQL. You can vote for the idea to allow this. You didn't really specify the context for this. If it's a trigger context, then you already have the records. I'd be worried about your query size if you have millions of accounts and no real way to narrow down which ones you want to check the Notes of ...


2

Your OR/AND was all confused, it should have been OR(A,AND(B,C),AND(D,E)). I realize this looks weird, as you were probably expecting it to look like A OR(B AND C)OR(D AND E), but that's not how formulas work. Also, to return true or false, you don't need IF; a Boolean value is already a Boolean value (I know this sounds obvious, but so many people seem to ...


2

Unfortunately, since the second string is looking for a partial text match, I don't see a way to avoid looping over each element to compare them. If you had a full text element match, the inner loop could be removed in favor of a Set contains() method. You should be careful of this "loop within a loop" approach. Unless you have tight control of ...


2

It appears from your debug statements and the code you have, that the inputs were actually surrounded by quotes: “12345” and “1234”, rather than 12345 and 1234. In this case, neither string will return .contains because of the quotes. / Mismatch at 5. “12345” “1234” \ Mismatch at ”. Thus, I suspect the problem is not in your code, but in your ...


1

You could do this with regex but a simple solution is: if (myString.contains('VA') && !myString.contains('IVA')) { ... do field update }


1

You can separate the different options using multiple CONTAINS functions in an OR function: <apex:outputText rendered="{!IF(OR(CONTAINS(Intake__c.Personal_Care__c, 'Toileting'), CONTAINS(Intake__c.Personal_Care__c, 'Bathing'), CONTAINS(Intake__c.Personal_Care__c, 'Self-Care in Bathroom')), 'true', 'false')}" value="value a"/> There'...


1

Taking Kris's answer a little further, if the context is outside the Account trigger, in order to get a set of candidate Accounts that may be what you are looking for - i.e. ones that include the search term at least once, somewhere (may not be in your long text field, but it may be) - tha you can then filter down, try something like: String searchTerm = '...


1

The examples you gave are incorrect. Since you were using containsIgnoreCase(), the case is (unsurprisingly) ignored. Since "Coordinator" does, in fact, contain "coo", the containsIgnoreCase() method is rightly returning true. String.contains(), on the other hand, is case-sensitive You can run the following snippet to verify String s1 = 'COO'; String s2 =...


1

The field map returns keys in all lowercase, but you're using proper-casing. This is what's causing the problem. A better alternative would be to make sure the field is in the describe map. This eliminates the need for the try-catch block. for (String fieldName : fieldToSync) { if(fieldMap.containsKey(fieldName) && newjobApp.get(fieldName) ...


1

I found a work-around to this. I just carried over the lookup__r.name into a formula field onto the object with text_field__c. then I used contain there to evaluate it.


1

Refer CONTAINS function use cases and examples article. Usage Search for text. Check if an unknown string or character matches a defined set of strings or characters. Example of searching for text. CONTAINS(Comments__c,"BadWord") Returns TRUE if "BadWord" is found anywhere in Comments__c. Example of searching for unknown string or characters. ...


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