As per documentation(or should i say popular belief … as i did not find exact documentation link) 18 digits are case insensitive and 15 digit ids are case sensitive.
In fact many site blogs says that 18 digits was invented to ignore case of characters in id field.
When I tested it in developer console and workbench it did not work as expected.
For ex, my account id is ‘0019000001AWn2o’. In 18 digit format it is ‘0019000001AWn2oAAD’
Now, if we change case of any characters in 18 digit id then also system should work. (At least that is what interpretation about case insensitive ID)
But to my surprise non of following ids work in SOQL ,URL or from API
- 0019000001AWn2oAAd
- 0019000001aWn2oAAD
- 0019000001AWn2OAAD
So, what it seems like the popular belief is wrong that 18 digits are case insensitive. But last 3 digit just act as check sum for validation.
I know that we can decode the 18 digit id and get the original 15 digit id but i was expecting that platform should have handle it when I pass 18 digit id.
Am i missing something here?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
The parity bits are meant to help systems that ignore case sensitivity to properly find records where the short Ids differ only by case. For example, SOSL can’t tell between case, so if you’re logging Ids into a text field, the long Id will correctly find just the records you want.
It does not mean you can, or should, freely modify an Id’s case. It simply means that systems that can’t tell between lowercase and uppercase, usually as a convenience to users, won’t match up records incorrectly.
In general, you should always prefer to use the long Id when possible, as it increases interoperability with various systems.
As an example, consider these two ID values:
0019000001AWn2oAAD 0019000001awn2oAAA
If you were to use just the 15-character form, they then look like this:
0019000001AWn2o 0019000001awn2o
If you try to compare them in Excel, you get an “unexpected” result:
="0019000001AWn2o"="0019000001awn2o" (TRUE)
This makes normal VLOOKUP functions fail, because Excel doesn’t normally care about case sensitivity.
However, using the long version:
="0019000001AWn2oAAD"="0019000001awn2oAAA" (FALSE)
Solves the case insensitivity issue. This allows the external system to properly match up records when it considers uppercase and lowercase to be an equal value.
Method 2
The 18-digit Id is only case-insensitive in regards to uniqueness. It will not work for queries/urls/etc. without proper casing.
You’re not the first one to experience this issue. As far as I can tell, @DanielBallinger was the first to explain how to fix the casing of an Id here (via C#) and there are a couple ports to Apex here.
Method 3
18 digit case-insensitive version which is referenced through the API.
The last 3 digits of the 18 digit ID are a checksum of the capitalizations of the first 15 characters, this ID length was created as a workaround to legacy systems which were not compatible with case-sensitive IDs.
The API will accept the 15 digit ID as input but will always return the 18 digit ID.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0