1、這段linq,執行期間報ora-12704:character set mismatch錯誤。
1 var query = from m in ctx.MENU 2 where (m.SUPER_MENU_ID ?? "") == (parentMenuId ?? "") 3 orderby m.SORT_ID descending 4 select new { m.SORT_ID };
生成出來的sql如下:
1 SELECT "Project1"."SORT_ID" AS "SORT_ID" 2 FROM ( 3 4 SELECT "Extent1"."SORT_ID" AS "SORT_ID" 5 FROM "BA"."MENU" "Extent1" 6 WHERE ((CASE WHEN("Extent1"."SUPER_MENU_ID" IS NULL) THEN '' 7 ELSE "Extent1"."SUPER_MENU_ID" END) = 8 (CASE WHEN(&p__linq__0 IS NULL) THEN '' 9 ELSE &p__linq__0 END)) 10 11 ) "Project1" 12 ORDER BY "Project1"."SORT_ID" DESC
但是這條sql單獨放到plsql里跑是OK的。
2、改成這樣,讓生成的sql去掉了里面的case when就OK了。
1 parentMenuId = parentMenuId ?? ""; 2 var query = from m in ctx.MENU 3 where m.SUPER_MENU_ID == parentMenuId 4 orderby m.SORT_ID descending 5 select new { m.SORT_ID };
生成的sql如下:
1 SELECT "Project1"."SORT_ID" AS "SORT_ID" FROM ( 2 3 SELECT "Extent1"."SORT_ID" AS "SORT_ID" 4 FROM "BA"."MENU" "Extent1" 5 WHERE ("Extent1"."SUPER_MENU_ID" = :p__linq__0) 6 7 ) "Project1" 8 ORDER BY "Project1"."SORT_ID" DESC
3、目前的猜測是,ef生成出來的case when有問題,調整linq不生成case when即可。但奇怪的是,同樣的sql在plsql里跑居然也是ok的,手工修改客戶端的字符集也無法在plsql里重現這個問題,如下:
修改注冊表里,HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraClient11g_home2\NLS_LANG,在plsql里客戶端使用不同於服務端的字符集,但無法生成同樣的錯誤。
修改前:
NLS_LANG = SIMPLIFIED CHINESE_CHINA.ZHS16GBK
Character Sets
Character size: 2 byte(s)
CharSetID: 852
NCharSetID: 2000
Unicode Support: True
NLS_LANG: SIMPLIFIED CHINESE_CHINA.ZHS16GBK
NLS_CHARACTERSET: ZHS16GBK
NLS_NCHAR_CHARACTERSET: AL16UTF16
修改后:
NLS_LANG = SIMPLIFIED CHINESE_CHINA.AL32UTF8
Character Sets
Character size: 2 byte(s)
CharSetID: 873
NCharSetID: 2000
Unicode Support: True
NLS_LANG: SIMPLIFIED CHINESE_CHINA.AL32UTF8
NLS_CHARACTERSET: ZHS16GBK
NLS_NCHAR_CHARACTERSET: AL16UTF16
4、updated on 2014.06.03,問題有了新的線索,下面這條linq仍然會報同樣的錯誤:
R1 == null ? string.Empty : R1.Emp_ID
但把string.Empty改成""就OK,很怪:
R1 == null ? "" : R1.Emp_ID
5、這個問題只是暫時解決,仍然存疑中,待完善。主要參考這篇:
