I know this is an old one, but did anyone ever find a good way around Quickbase's issue here?
Until today, I had no idea QuickBase had this limitation. I now have two salesforce IDs that are identical except for a single letter being a different case. In this case, searching in reports, running queries (IE, {6.EX.'abc'}), all broken on this one.
Example:
00300002000010A
00300002000010a
(these ARE NOT equal - no matter what you believe)
Is there an actual solution here, or do I need to do yet another workaround in Quickbase?
Anyone reading this in the future and as aggravated as I am now, here are the two options I'm looking at - they're both duct tape, as the first doesn't scale and the second one doesn't account for non-ASCII characters:
- I already write the salesforce ID into a "Raw" field, then have a formula field that strips any characters after the 15th, and all functions use the formula field not the raw field - given this setup, I may alter the formula field to also rewrite one of the IDs that Quickbase faceplants on. Bad part is I'd need to have an alignment report that alerts me when duplicates happen - which is not ideal.
- I may do something such as convert the ID. As all characters fit within the original ASCII character set, I'm thinking convert to ASCII value and store a parallel string using Hex - IE, an "A" would be a decimal 65 in ASCII, so in the parallel case sensitive field it would be written as "41". A lowercase "a" would be decimal 97, so it would be written as "61". This parallel formula field would have values that were always 30 characters in length (1 original char = 2 hex chars, and salesforce is 15 chars) would only be used for comparisons, with visual element always being the original form of the ID, not the duct-tape form.
Quickbase - if you guys have this figured out finally, please let me know - until then, duct tape it is.
Everyone else - hope you were able to find this before it caused any issues, like incorrect executive reports!