影响DATE数据类型的环境变量解析

经常碰到用户说从一个库导出来的数据，到另一个库导入，或者插入数据，报失败（1205: 日期中的月份错误）。该问题其实date跟环境变量有很大关系，涉及到DBDATE，GL_DATE，CLIENT_LOCALE环境变量。
在"美国英语"，即en_US环境下，DBDATE 的缺省值为 MDY4/（即12/31/2020这样的格式）。在其他环境时，DBDATE不使用缺省值，如DB_LOCALE/CLIENT_LOCALE=zh_CN.utf8时，date的格式为（2020 12月 31日），此时操作date类型的数据时，很可能就会碰上1205错误，比如：

> select date('2020-12-03') from dual;

 1205: 日期中的月份错误
错误在 1 行
第 34 字符

为解决该问题，我们需要在客户端指定DBDATE或者GL_DATE的格式，如：

[gbasedbt@a02 ~]$ export GL_DATE="%iY-%m-%d"
[gbasedbt@a02 ~]$ dbaccess dbutf8 -

数据库已被选用。

> select date('2020-12-03') from dual;

(constant) 

2020-12-03

查询到 1 行。

DBDATE 变量的设置优先于 GL_DATE 环境变量的设置，并且优先于 CLIENT_LOCALE 指定的任何缺省 DATE 格式。
即，如果客户端同时有DBDATE和GL_DATE环境变量时，DBDATE生效。

[gbasedbt@a02 ~]$ export DBDATE=MDY4-
[gbasedbt@a02 ~]$ dbaccess dbutf8 -

数据库已被选用。
# 当前GL_DATE的格式为 %Y-%m-%d，DBDATE的格式为MDY4-，故该操作报错
> select date('2020-12-03') from dual;

 1204: 日期中的年份错误
错误在 1 行
第 34 字符
> select date('12-03-2020') from dual;


(constant) 

12-03-2020

查询到 1 行。

同样的，如果服务端设置了DBDATE，而客户端也设置了DBDATE或者GL_DATE或者CLIENT_LOCALE，那么将会优先使用客户端配置。如下图的优先级列表

综上所述，如果我们需要保持date类型的输出样式一致，如果我们使用的是非en_US环境时，需要明确的指定DBDATE或者GL_DATE环境变量，否则将会使用CLIENT_LOCALE带来的格式（这个格式大概率不是我们需要的）。