You need to sign in to do that
Don't have an account?
mmcconna
Ids - sometimes 15-character, sometimes 18-character for same objects?
Hi all. I'm confused, and would welcome some help. In an activities-based report within salesforce.com, I use the Activity Id field to give the Id number.
I then export to Excel. Let's say the Excel spreadsheet contains only one Actitivity, Id is 00U20000001Rx6d
Later, we read back the spreadsheet with some changes. I build an SOSQL string like this:
SELECT Id,Outcome__c,TookPlace__c FROM Event WHERE ( Id='00U20000001Rx6d')
and I get one Event (the right one) back, which I read into a keyed dictionary. However, the Event object I read from the API has an Id of 00U20000001Rx6dEAC.
So why is it that the report gives 15-character Ids, and the API reports 18-character Ids on the same item? It makes it difficult to match them up. Is it always safe to reduce the 18-character Id to a 15-character one?
Yours,
Moray
I then export to Excel. Let's say the Excel spreadsheet contains only one Actitivity, Id is 00U20000001Rx6d
Later, we read back the spreadsheet with some changes. I build an SOSQL string like this:
SELECT Id,Outcome__c,TookPlace__c FROM Event WHERE ( Id='00U20000001Rx6d')
and I get one Event (the right one) back, which I read into a keyed dictionary. However, the Event object I read from the API has an Id of 00U20000001Rx6dEAC.
So why is it that the report gives 15-character Ids, and the API reports 18-character Ids on the same item? It makes it difficult to match them up. Is it always safe to reduce the 18-character Id to a 15-character one?
Yours,
Moray
SF (and SF API) will recognize 15 and 18 char Ids fine.
Harry
Thank you for contacting salesforce.com Technical Support in regards to the API. 18-character ID values are simply 15-character ID values with a checksum suitable for case-insensitive searches. If you are using a case-sensitive application to match up ID values, you may safely discard the checksum characters. Otherwise, you will need to generate a checksum from the report's 15-character ID values to obtain the 18-character ID value. This is done by creating an zero-based indexed array of [A..Z0..9], then grouping the 15 characters into three groups of 5 characters. Each group creates a bitmask, where 1 is if the letter is uppercase, 0 if lowercase or a number. This five-bit number indexes into the array above. For example:
15-character ID: 00130000000Az53
Bitmask grouping: 00130 | 00000 | 0Az53
Bitmask: 00000 | 00000 | 01000
Indexing: array[0] = "A"; array[0] = "A"; array[8] = "I";
Final 18-character ID: 00130000000Az53AAI
Hopefully this makes some sense. If you are using case-sensitive environments, it's easier to just ignore the final three characters. However, if you need to use the ID values in a case-insensitive manner, this is how you can convert the report values to case-sensitive ID values. For additional information, please browse the Developer Forum for additional information.