我服了, 之前明明好用的一个函数里用了jdom_t, 突然就不行了 第47 行附近出现错误[-2119]:无效的过程/函数名[PUT]
第34 行附近出现错误[-3325]:包/对象[JDOM_T]解析失败 这应该不是jdom_t能不能用作函数参数的问题, 是这个jdom_t不知道怎么又失效了 想编译看看还没有权限, 真是服死了

SQL> SP_CREATE_SYSTEM_PACKAGES(0);
DMSQL 过程已成功完成
已用时间: 00:00:03.753. 执行号:5603.
SQL> SP_CREATE_SYSTEM_PACKAGES(1);
警告: 创建的对象带有编译错误
DMSQL 过程已成功完成
已用时间: 00:00:03.553. 执行号:5604.

这又是为啥

SQL> SP_CREATE_SYSTEM_PACKAGES(0, 'DBMS_JSON');
DMSQL 过程已成功完成
已用时间: 192.499(毫秒). 执行号:602.
SQL> SP_CREATE_SYSTEM_PACKAGES(1, 'DBMS_JSON');
警告: 创建的对象带有编译错误
DMSQL 过程已成功完成
已用时间: 126.246(毫秒). 执行号:603.

破案了: COMPATIBLE_MODE = 0 #Server compatible mode, 0:none, 1:SQL92, 2:Oracle, 3:MS SQL Server, 4:MySQL, 5:DM6, 6:Teradata, 7:PG 这个参数改成2 兼容oracle 然后这个DBMS_JSON包含的 jdom_t json_object_t 等等就解析失败了. 我用 sqlark 迁移数据的时候, 工具提示改的兼容模式, 不知道是谁的锅, 按说这个应该没关系啊, oracle下也是有 jdom_t json_object_t的呀

我后来把dm.ini中的 COMPATIBLE_MODE 设置为2 的同时, 把所有询问是否兼容oracle的选项, 都设置为兼容. 之后就没问题了.

开启兼容oracle后需再开启ORA_DATE_FMT参数，重启服务
SP_SET_PARA_VALUE (2,'ORA_DATE_FMT',1);