We have a system that automatically uppercase's all characters in the salesforce 18 character ID, so for example 0060H00000mbAZlQAM versus 0060H00000MBAZLQAM. Salesforce does not accept the latter as valid whereas the former is valid, which is contrary to our memory of how the case insensitive ID's worked. Is there any information on how to get the proper case sensitive ID from the case insensitive ID (One where the 15 char bit has had its cases jumbled up)?
5
-
118-char Ids are case-safe - any two 18-character Ids always differ from one another more than in the case of their component characters. They are not case-insensitive. There's a couple of answers here that aim to restore lost case information (I have not tried them myself).– David Reed ♦Feb 4, 2019 at 19:26
-
Which is what are understanding currently is, but why does salesforce when querying the latter say id does not exist? The last 3 characters are supposed to 'insensitize' the first 15 characters. So changing the cases of a 18 character ID (except last 3) should do nothing to salesforce right?– Zach HutchinsFeb 4, 2019 at 19:29
-
3From Salesforce's perspective, it doesn't exist. Your external system has fed it a corrupt Id. The 3-character "checksum" is for the benefit of external systems that aren't case-safe, but Salesforce won't use it to restore lost case information. Your integrations will have to do that additional step. See Daniel Ballinger's answer on the linked question for an example.– David Reed ♦Feb 4, 2019 at 19:35
-
1@ZachHutchins David's right. You can't mess with the casing of the ID values. The extra three characters are used for situations like Excel or MySQL in case-insensitive modes. Salesforce still requires the correct casing of all the characters in order to do anything with the ID (query, DML operation, etc).– sfdcfoxFeb 4, 2019 at 19:38
-
This duplicate might help you more than what's already linked. salesforce.stackexchange.com/q/123217/2995– Adrian Larson ♦Feb 4, 2019 at 20:20
Add a comment
|