1、这段linq,执行期间报ora-12704:character set mismatch错误。
1 var query = from m inctx.MENU2 where (m.SUPER_MENU_ID ?? "") == (parentMenuId ?? "")3 orderbym.SORT_ID descending4 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 inctx.MENU3 where m.SUPER_MENU_ID ==parentMenuId4 orderbym.SORT_ID descending5 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、这个问题只是暂时解决,仍然存疑中,待完善。主要参考这篇:
原文:http://www.cnblogs.com/AlexanderYao/p/3571702.html