在18個字符的ID編碼的先前字符的大寫/小寫的最後3個字符,從而使對象的長ID可以爲等值也在不區分大小寫的編程語言進行比較。您可以使用您所獲得的短或長ID。 (您的ID爲16個字符,無效)
更新的對象僅由type
和主鍵id
標識。所有其他名稱都是更新的列。因此,如果您不更新它,您可以忽略「名稱」。
dtto
編輯 解釋「你可以用你得到的,無論是短期或長期ID」:
上SFDC 一切都接受短期或長期ID (Web界面,Apex,VisualForce,API,導入數據等)內部頂點代碼以及瀏覽器中的網址,視圖和報表使用15個字符,因爲它保證處理區分大小寫。每個輸出(如備份,從報表,開發者控制檯或Salesforce API導出)都有18個字符的ID,可以輕鬆處理,不區分大小寫。由Excel。
您可能永遠不需要去掉或添加最後3個字符。唯一的問題可能是,如果將從瀏覽器複製/粘貼的ID與導出的數據結合起來,還可以選擇不區分大小寫的搜索或比較的工具,則可以使用一些方法來區分大小寫。您也可以獲得長ID,例如通過功能CASESAFEID()
在Apex中或由SELECT Id from Account WHERE Id = 'short_id...'
在Beatbox中或通過我的函數case_safe_id在Python中脫機,但我重複說我真的不需要它。(除了更準確地猜測字符串可能是有效的Salesforce ID:未找到ID或Salesforce報告的ID無效)爲了簡單區分大小寫搜索Excel中工作表中包含的短ID,可以使用安全,因爲ID有這樣的結構:
ID structure:
TTTII0XXXXXXXXXCCC
TTT = type of object
II = server instance where the data row was originally created
0 = it is still guaranteed zero at this position, but can be subject of change
XXXXXXXXX = ID of the row, jumping, but approximately increasing in a long-term scale
CCC = encoded case sensitive info
因此在漫長的ID搜索到的短ID的比賽只可能正好在開始。
編輯2 Salesforce recommends that you use the 18-character ID.(開發者指南)
,如果你通過一個呼叫建立多行在一起,可以創造出巨大的類似15個字符的ID的數量:svc.create(list_of_200_rows_data)
。有趣的是ID和Lookup字段是區分大小寫的,即使是短字符SELECT Id, Name FROM Contact WHERE AccountId = '0010000ID15CHAR'
,而文本字段不區分大小寫SELECT FirstName FROM Contact WHERE LastName='sMiTh'
。因此,如果您爲從其他Salesforce數據庫遷移的行保存了一些 「old_id」(必須將其保存爲文本),則必須將其保存爲18個字符的ID
謝謝。然後,我將刪除'姓名'字段。此外,如果我傳遞的身份證有18個字符,銷售隊伍中有15個字符,如何更新beatbox?僅供參考:我正在使用python,因此它確實考慮了我認爲的大小寫敏感性。問題是,如果我截斷了18的最後3個字符,那麼有2個賬號具有相同的15個字符。如何處理它? – Gagan
謝謝我將16改爲15.這是一個錯字。 – Gagan
我正在使用excel查看重複項,因此可能是excel不區分大小寫,或者必須有某種方式將15個字符與18個字符進行比較。 – Gagan