【无标题】

@维护老项目的时候的坑，死坑死坑 jbpm_log主键冲突

10年前的老项目，使用了jbpm。发起流程时总是主键冲突

正在维护的一个老项目使用jbpm，在发起流程的时候。 jbpm_log表主键冲突。维护得头都大了。也不想去找jbpm到底使用的是什么版。就想着把oracle的sequence修一下。but,jbpm使用的是哪个呢？里面有一个sqe_bpm_my_suggestion的。看着挺像，但是改了不起作用。就想知道是不是没有用这个，于是删除了。报错。序列找不到。。。。我去，用了，但是不是这个。

查了jbpm的文件主键生成方式，发现，我走偏了。

经过痛苦的搜索找到一个贴子，上面写着 试一下 hibernate_sequence. 于是解决了。。。真坑啊。。。那么多sequence…唉。找不到简直能急死人。这也不是什么高级东西。。但就是恶心人。

原贴
BPM3报错ORA-00001:违反唯一约束条件（A.SYS_C001234）
[日期：2016-12-29] 来源：Linux社区 作者：JanceD [字体：大 中 小]
我用的是比较老的jbpm版本3.2.3，由于数据库迁移，把jbpm数据导出后，再导入新的数据库，应用就会报错ORA-00001:违反唯一约束条件（A.SYS_C001234）

上网没查到如何解决这个问题，一是jbpm版本太老，二是jbpm本来用的人就不多。
经过仔细查找，终于解决了这个问题，现记录下来，以供参考。

首先，我先搜索这个SYS_C001234是个啥，发现它是jbpm某表中的主键id_的index，那就可以推测是jbpm的所有表中id的最大值（因为jbpm所有表id生成共用一个序列），已经超过序列的next number，而这个next number是创建jbpm新数据的id值。老值大于新值，也就是说这个新值已经存在了，无法使用，最佳解决方案就是更改序列的next number。
然后，我在jbpm创建表的sql文档中发现了一个sequence，叫hibernate_sequence，打开这个序列，再对比jbpm其他表的id最大值（我对比了jbpm_log表，这个表使用最多，最大值最可能在这里），果然，最大id已经超过序列，把序列的next值修改成大于最大id的数值就解决了这个问题！

哇哈哈哈哈jbpm3报错ORA-00001:违反唯一约束条件（A.SYS_C001234）