【活躍論壇氣氛】之數據庫

Question

    先發一些我平時遇到的問題和筆記，希望能對各位有幫助。先發3個條目，太長了也不好，看效果如何？或者有什么建議，可以提出來，后續就可采納。錯誤之處，請見諒并指正。謝謝！    1、一些常見的SQL效能調整；    2、由存儲過程(StoredProcedure)引發的 "无法解决 equal to 操作的排序规则冲突。"
    StoredProcedure中使用了暫存#TempTable
      Ex:
     Create Table #TempTable
      (Field01 varchar(10),
       Field02 varchar(20))以上在繁體SQLServer中Field1 & Field2預設的COLLATE為Chinese_Taiwan_Stroke_CI_AS在簡體SQLServer中Field1 & Field2預設的COLLATE則為Chinese_PRC_CI_AS(這是因為暫存#TempTable預設的COLLATE為系統tempdb的COLLATE的關係,且tempdb為系統數據庫,不允許使用Alter DataBase去變更COLLATE)而於繁體數據庫中,所有的Table中char / varchar預設皆為Chinese_Taiwan_Stroke_CI_AS如此只要Join了不同COLLATE的Field,就會引發錯訊 "无法解决 equal to 操作的排序规则冲突。"
要解決上述的問題有以下3種方式:  1）、 於Create Table #TempTable時,註明每個Field的COLLATE…Ex: Create Table #TempTable(Field01 varchar(10) COLLATE database_default, Field02 varchar(20) COLLATE database_default)以上char / varchar皆註明COLLATE database_default,其中database_default的意義為告訴SQLServer說,這個#TempTable的COLLATE請參照目前連結的DB,而不要去參照tempdb或Create Table #TempTable(Field01 varchar(10) COLLATE Chinese_Taiwan_Stroke_CI_AS,Field02 varchar(20) COLLATE Chinese_Taiwan_Stroke_CI_AS)以上char / varchar皆註明特定的COLLATE,以確保 #TempTable的COLLATE和我們DB中Table的COLLATE保持一致,而不要再去參照tempdb2）、   在Join實體Table與#TempTable時註明COLLATE為何Ex:Select * From Table1 t1, #TempTable t2Where t1.Field01 = t2.Field01Collate Chinese_Taiwan_Stroke_CI_AS -- 在Select的最後註明要使用的COLLATE為何3）、  繁體的SQLServer使用繁體的DB / 簡體的SQLServer使用簡體的DB,不要交叉互相使用,也就是在SQLServer中固定使用與該SQLServer預設相同COLLATE的Table,也就是在繁體的SQLServer中Create繁體用的DB後,再Create Table & Field,如此預設所有Field的COLLATE就會是Chinese_Taiwan_Stroke_CI_AS而在簡體的SQLServer中Create簡體用的DB後,再Create Table & Field,如此預設所有Field的COLLATE就會是Chinese_PRC_CI_AS
    3、“...WHILE ATTEMPTING TO OPEN OR CREATE...”，數據庫創建失敗問題
用程式創建一個sql server 資料庫時，出現了“...WHILE ATTEMPTING TO OPEN OR CREATE...”，資料庫創建失敗。看起來是沒有權限的關系。但是在studio里面是可以創建的。後來查找sql configuration management （組態管理員），發現sql server 及sql agent登入身份都是networt service。據查資料，若系統服務netlogon沒有啟動的話，那么sql以這種身份登入，權限是無法被識別的。或是獨立型的服務器，采用這種方式登錄也不行。解決方式是把登入身份改為本地帳戶（透過組態管理員）
   

Answer 1

    4、SQL Server的排序與D2009的字串比較問題
     問題狀況：“王” 與 “何” 用sql排出來 與 D2009下字串的比較結果不同。
     解決過程： 
     1). 非 Unicode(Big-5) 排序方式 , 大致上原則是依照筆劃->部首->筆順 (或其他設定),
       Windows 系統內建有排序表 , 所以是 “王” < “何”     2). Unicode 排序方式  , 是依照 部首、筆劃  , 所以是 “何” < “王”     3). 所以 Delphi2009 本身是沒有錯誤的 , 至少他忠實的呈現 Unicode 的排序 ,
       但呈現的方式和使用者預期的不同 , 所以成為問題     4). SQL 原則上在沒有特殊設定的狀況下也沒有錯 , 因為他會自動依照Windows 的原則來排序     那麼現在要解決的問題就是 , 怎麼讓呈現出來的結果符合預期結果     CompareStr 有兩個 , 第二個可以多傳一個參數 , 指定使用使用者機器的選項
      function CompareStr(const S1, S2: string): Integer; overload;
     function CompareStr(const S1, S2: string; LocaleOptions: TLocaleOptions): Integer; overload;     而實際上內部是
    if LocaleOptions = loUserLocale then
      Result := AnsiCompareStr(S1, S2)
    else
      Result := CompareStr(S1, S2);    查看 AnsiCompareStr , 雖然名稱帶的是 Ansi , 但內部是呼叫 Windows Api CompareString
{ AnsiCompareStr compares S1 to S2, with case-sensitivity. The compare
  operation is controlled by the current user locale. The return value
  is the same as for CompareStr. }   
        程式碼是 :
  Result := CompareString(LOCALE_USER_DEFAULT, 0, PChar(S1), Length(S1),
      PChar(S2), Length(S2)) - CSTR_EQUAL；
 
    但注意看可以看到參數都是 PChar , 而不是 PAnsiChar , 再往下看可以發現 CompareString不是
     Ansi 的 , 正確的應該是 'CompareStringW' , 支援 WideString 的
   function CompareString; external kernel32 name 'CompareStringW';       結論：在sql server預設排序狀況，D2009下字串的比較用此function CompareStr(const S1, S2: string; LocaleOptions: TLocaleOptions): Integer; overload;才能與Sql server相符

Answer 2

   5、Interbase與FireBird的sql 語法兼容問題
      這兩種數據庫，現在應該很少人在用了，希望對還在用的人有幫助，沒有用過的，就當沒看見吧 ^_^

Answer 3

 .
上次的MARK居然没提交上去 ：(

Answer 4

顶一个..............
收下了..........THANKS!!!!!