全球化秘訣和最佳做法 （Analysis Services）

適用於： SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

重要事項：本文 資訊僅適用於 多維度 模型解決方案。

這些秘訣和指導方針可協助增加多維度商業智慧解決方案的可移植性，並避免與語言和定序設定直接相關的錯誤。

在整個堆疊中使用類似的定序

可能的話，請嘗試在 SQL Server Analysis Services 中使用您用於資料庫引擎的相同定序設定，並努力在區分寬度和區分大小寫和區分大小寫的對應，以及存取敏感度。

每個服務都有自己的定序設定，資料庫引擎預設設定為 SQL_Latin1_General_CP1_CI_AS，Analysis Services 設定為 Latin1_General_AS。 預設值在大小寫、寬度和區分腔調字方面相容。 請注意，如果您改變任一定序的設定，當定序屬性以基本方式分歧時，可能會發生問題。

即使定序設定在功能上是相等的，您也可以遇到特殊情況，其中字元串內的任何空空格會以不同的方式由每個服務解譯。

空格字元是「特殊案例」，因為它可以在 Unicode 中以單一位元組 （SBCS） 或雙位元組字元集 （DBCS） 表示。 在關係型引擎中，以空格分隔的兩個複合字串，其中一個使用 SBCS，另一個在 DBCS 中則視為相同。 在 Analysis Services 中，在處理期間，相同的兩個複合字串不相同，而第二個實例會標示為重複。

如需詳細資訊和建議的因應措施，請參閱 Unicode 字串中的空白 根據定序有不同的處理結果。

常見的定序建議

Analysis Services 一律會提供所有可用語言和定序的完整清單;它不會根據您選取的語言來篩選定序。 請務必選擇可行的組合。

一些較常用的定序包括下列清單中的定序。

您應該將此清單視為進一步調查的起點，而不是排除其他選項的明確建議。 您可能會發現，未特別建議的定序是最適合您數據的定序。 徹底測試是驗證數據值是否經過適當排序和比較的唯一方法。 一如往常，請務必在測試定序時執行處理和查詢工作負載。

• Latin1_General_100_AS通常用於使用 ISO 基本拉丁字母26 個字元的應用程式。

• 包含斯堪的納維亞字母（如 ø）的北歐語言可以使用Finnish_Swedish_100。

• 東歐語言，如俄文，經常使用Cyrillic_General_100。

• 中文和定序會因地區而異，但通常是簡體中文或繁體中文。

  在中國和新加坡，Microsoft支援傾向於看到簡體中文，拼音是慣用的排序順序。 建議的定序為Chinese_PRC（適用於 SQL Server 2000）、Chinese_PRC_90（適用於 SQL Server 2005）或Chinese_Simplified_Pinyin_100（適用於 SQL Server 2008 和更新版本）。

  在臺灣，使用建議排序順序的繁體中文比較常見：Chinese_Taiwan_Stroke（適用於 SQL Server 2000）、Chinese_Taiwan_Stroke_90（適用於 SQL Server 2005）或Chinese_Traditional_Stroke_Count_100（適用於 SQL Server 2008 和更新版本）。

  其他地區（如香港特別行政區和澳門特別行政區）也使用繁體中文。 對於定序，在香港特區，看到Chinese_Hong_Kong_Stroke_90（在 SQL Server 2005 上）並不罕見。 在澳門特別行政區，Chinese_Traditional_Stroke_Count_100（SQL Server 2008 及更新版本）經常使用。

• 對於日文，最常使用的定序是Japanese_CI_AS。 Japanese_XJIS_100用於支援 JIS2004的安裝。 在數據遷移專案中，通常會看到Japanese_BIN2，數據源自非 Windows 平臺，或來自 SQL Server 關係資料庫引擎以外的數據源。

  執行 Analysis Services 工作負載的伺服器很少看到Japanese_Bushu_Kakusu_100。

• 建議使用韓文Korean_100。 雖然清單中仍然提供Korean_Wansung_Unicode，但已被取代。

對象識別碼的區分大小寫

從 SQL Server 2012 SP2 開始，對象識別碼的區分大小寫會與定序無關強制執行，但行為會因語言而異：

物件識別符區分大小寫的影響

只有物件標識碼，而不是物件名稱，會受限於數據表中所述的大小寫行為。 如果您看到解決方案的運作方式變更 （比較前後 -- 安裝 SQL Server 2012 SP2 或更新版本之後），則很可能是處理問題。 查詢不會受到物件標識碼的影響。 針對這兩種查詢語言 （DAX 和 MDX），公式引擎會使用物件名稱（而非標識符）。

使用 Excel、SQL Server Profiler 和 SQL Server Management Studio 的地區設定測試

測試翻譯時，連接必須指定翻譯的 LCID。

您可以手動編輯 .odc 檔案以包含地區設定識別碼連接字串屬性來執行此動作。 使用 Adventure Works 範例多維度資料庫試試看。

• 搜尋現有的 .odc 檔案。 當您找到 Adventure Works 多維度的檔案時，以滑鼠右鍵按兩下檔案，以在 [記事本] 中開啟它。

• 將 Locale Identifier=1036 新增至連接字串。 儲存並關閉檔案。

• 開啟 Excel |數據 | 現有的連接。 將清單篩選為只連接這部電腦上的檔案。 尋找 Adventure Works 的連線（仔細查看名稱;您可能有多個名稱）。 開啟連線。

  您應該會看到 Adventure Works 範例資料庫的法文翻譯。

  

接下來，您可以使用 SQL Server Profiler 來確認地區設定。 點選 Session Initialize 事件，然後查看下方文字區域中的屬性清單，以尋找 <localeidentifier>1036</localeidentifier>。

在 Management Studio 中，您可以在伺服器連線上指定地區設定識別碼。

• 在物件總管中 |Connect | Analysis Services | [選項]]，請按兩下 [[其他聯機參數] 索引卷 標。

• 輸入 Locale Identifier=1036，然後按兩下 [Connect]。

• 針對 Adventure Works 資料庫執行 MDX 查詢。 查詢結果應該是法文翻譯。

  在 SSMS 中使用法文翻譯

在包含翻譯的解決方案中撰寫 MDX 查詢

翻譯會提供 SQL Server Analysis Services 物件名稱的顯示資訊，但不會翻譯相同對象的標識碼。 盡可能使用 SQL Server Analysis Services 對象的識別碼和索引鍵，而不是翻譯的標題和名稱。 例如，使用成員索引鍵，而不是多維度表達式 （MDX） 語句和腳本的成員名稱，以確保跨多種語言的可移植性。

撰寫包含日期和時間值的 MDX 查詢

下列建議可讓您以日期和時間為基礎的 MDX 查詢在不同語言之間更容易移植：

1. 使用數值元件進行比較和作業

   當您執行月和周間比較和作業時，請使用數值日期和時間部分，而不是字串對等專案（例如，使用 MonthNumberofYear 而非 MonthName）。 數值受到語言翻譯差異的影響最小。

2. 在結果集中使用字串對等專案

   建置使用者看到的結果集時，請考慮使用字串（例如 MonthName），讓您的多語系物件可以從您提供的翻譯中獲益。

3. 針對通用日期和時間資訊使用 ISO 日期格式

   一位 Analysis Services 專家 有這項建議：「我一律使用 ISO 日期格式 yyyy-mm-dd，用於我傳入 SQL 或 MDX 中查詢的任何日期字元串，因為它明確，無論用戶端或伺服器的區域設定為何，都會運作。 我同意伺服器在剖析模棱兩可的日期格式時，應該延後其地區設定，但我也認為，如果您有一個選項，無法解釋，無論如何，您最好選擇它“。

4. 使用 Format 函式來強制執行特定格式，不論區域語言設定為何

   下列從論壇文章借用的 MDX 查詢說明如何使用 Format 傳回特定格式的日期，而不論基礎區域設定為何。

   WITH MEMBER [LinkTimeAdd11Date_Manual] as Format(dateadd("d",15,"2014-12-11"), "mm/dd/yyyy")  
   member [LinkTimeAdd15Date_Manual] as Format(dateadd("d",11,"2014-12-13"), "mm/dd/yyyy")  
   SELECT  
   { [LinkTimeAdd11Date_Manual]  
   ,[LinkTimeAdd15Date_Manual]  
   }  
   ON COLUMNS   
   FROM [Adventure Works]  
   
   

另請參閱

Analysis Services 的 全球化案例
撰寫國際 Transact-SQL 聲明