启动报 Flowable dbVersionProperty 空指针，表名大小写不一样怎么办？

问题

客户导入 schema_*.sql + static_data_*.sql 后启动失败，常见栈：

text

java.lang.NullPointerException:
Cannot invoke "org.flowable.common.engine.impl.persistence.entity.PropertyEntity.getValue()"
because "dbVersionProperty" is null
    at org.flowable.engine.impl.db.ProcessDbSchemaManager.schemaUpdate(...)

或者生产关闭自动改表时：

text

FlowableWrongDbException: version mismatch: library version is '8.0.0.0', db version is null

Navicat 里 select * from act_ge_property 和 select * from ACT_GE_PROPERTY 查出的结果不一样。

答案

Linux 上 MySQL lower_case_table_names=0 时，大小写不同的表名是两张物理表。 Flowable 引擎读大写 ACT_GE_PROPERTY。

2026-08-19～08-25 的 dump：SQL 里是小写 act_ge_property（开发库 lctn=1 原样导出），在 Linux 默认库上会建成「数据在小写、引擎读大写空表」→ 空指针 / db version is null。
2026-08-25 的 dump：只改写了 ACT_* / FLW_*，Quartz 仍是小写 qrtz_*。Linux 上会报 Table '….QRTZ_LOCKS' doesn't exist。
2026-08-26 之后的 latest：导出脚本把 ACT_* / FLW_* / QRTZ_* 都改写成大写，lctn=0/1/2 都能用。不要靠改开发库「开启大小写区分」，也不要把 flowable.database-schema-update 改成 true 自愈。

已导入的小写包：把有数据的小写表 RENAME 成大写，或空库重导新 latest。

详细说明

1. 先确认是不是「两张表」

sql

SHOW VARIABLES LIKE 'lower_case_table_names';

SELECT TABLE_NAME
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND LOWER(table_name) = 'act_ge_property';

SELECT NAME_, VALUE_, REV_ FROM act_ge_property;
SELECT NAME_, VALUE_, REV_ FROM ACT_GE_PROPERTY;

现象	含义
`lower_case_table_names=1`（Windows / 部分云镜像）	两种写法指向同一张表，结果必然相同
`lower_case_table_names=0` 且查出两行 `act_ge_property` / `ACT_GE_PROPERTY`	就是这次问题：数据在一张，引擎读另一张
只有小写表有 `schema.version=8.0.0.0`，大写表空或没有该行	Flowable 启动读到的是空版本

官方 mysql:8 Linux 镜像默认经常是 0；我们开发库（移动云）是 1，所以本机/开发环境不容易复现。

2. 为什么会有小写 dump？

开发库（移动云）lower_case_table_names=1，SHOW CREATE TABLE 只能吐小写。8 月 15 日迁库后，导出脚本曾原样写出 act_ge_property。Flowable 在 lctn=0 上按历史惯例找大写 ACT_GE_PROPERTY。

长期方案：不改开发库，在 _export_static.mjs 写出 SQL 时把 act_* / flw_* / qrtz_* 改成大写。lctn=1 会折叠；lctn=0 建成引擎要的名字。

历史小写包导入后：

数据进小写表。
启动且 database-schema-update: true → 引擎可能再创建一套空的大写表。
schemaUpdate 读大写表 → dbVersionProperty == null。

application-prod.yaml 默认 database-schema-update: false，同一问题表现为 db version is null。

3. 不要做的事

不要把 flowable.database-schema-update 改成 true 当修复：表结构已在，空属性表 + 自动升级常见下一步是 Duplicate column。
不要只补大写表的 schema.version、不管其它 ACT_*：act_re_procdef / act_ge_bytearray 若也是「数据在小写、引擎读大写」，流程照样发不起来。
不要在大小写敏感库上把旧包（大写表名）和新包（小写表名）混导一遍。

4. 已导入库怎么处理

目标：库里 只保留一套 Flowable 表，且表名大小写与引擎一致（Linux lower_case_table_names=0 时用大写）。

列出重复表：

sql

SELECT table_name
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND (
    LOWER(table_name) LIKE 'act_%'
    OR LOWER(table_name) LIKE 'flw_%'
    OR LOWER(table_name) LIKE 'qrtz_%'
  )
ORDER BY LOWER(table_name), table_name;

确认数据在哪套：小写 act_ge_property 应有约 7 行，且含 schema.version = 8.0.0.0；act_re_procdef 应有流程定义（完整 static_data 约一百多条量级）。
删掉空的那套，把有数据的表 RENAME 成引擎使用的大写名，例如：

sql

-- 示例：大写表为空、数据在小写。先确认大写表无业务数据再 DROP。
DROP TABLE IF EXISTS `ACT_GE_PROPERTY`;
RENAME TABLE `act_ge_property` TO `ACT_GE_PROPERTY`;

ACT_RE_*、ACT_GE_BYTEARRAY、ACT_ID_*、FLW_*、QRTZ_* 等同理，不要只改一张属性表。

已导入 8 月 25 日包、只缺 Quartz 大写表时，11 张 qrtz_* 可一次性 RENAME（见 ruoyi-office-db/update/202608/20260826_update/02_optional_可选需确认/）。不要叠导新 schema。

改完再查：

sql

SELECT NAME_, VALUE_ FROM ACT_GE_PROPERTY WHERE NAME_ = 'schema.version';
-- 期望：8.0.0.0

新环境更稳妥：用 2026-08-26 之后 带大写 ACT_GE_PROPERTY 和 QRTZ_LOCKS 的 latest 空库重导。不要改已有实例的 lower_case_table_names（通常要重建数据目录）。我们 Docker 交付已强制 =1，与开发库一致，但 SQL 仍写大写以便覆盖 Linux 自建默认库。

5. 和「static_data 漏导」的区别

	表名大小写两套	static_data 漏了 Flowable 行
特征	小写、大写各一张，查询结果不同	只有一张表，但是空的 / 没有 `schema.version`
常见环境	Linux + `lower_case_table_names=0`	任意环境，只导了 schema 或旧导出白名单漏表
处理	合并/重命名为一套表	补 `8.0.0.0` 属性行或重导 static_data

版本号必须是 8.0.0.0，不要补成旧的 7.2.0.2。

涉及代码 / 配置

交付 SQL：ruoyi-office-db/dump/latest/schema_*.sql、static_data_*.sql（ACT_* / FLW_* / QRTZ_* 为大写；业务表小写）
导出改写：ruoyi-office-db/dump/_export_static.mjs → toDumpTableName / rewriteFlowableTableIdents
生产关闭自动改表：ruoyi-office/yudao-server/src/main/resources/application-prod.yaml → flowable.database-schema-update: false
开发默认会改表：application.yaml → database-schema-update: true（客户若用开发配置 + 小写历史包，更容易在 lctn=0 上建出第二套空表）

修订记录

日期	修改
2026-08-25	初稿（客户 Linux 库 `act_ge_property` 与 `ACT_GE_PROPERTY` 结果不同）
2026-08-25	长期方案：导出改写引擎表名为大写；不要改开发库 lctn
2026-08-26	补齐 Quartz：`QRTZ_*` 与 Flowable 一并改写；8 月 25 日包会报 `QRTZ_LOCKS` 不存在

问题 ​

答案 ​

详细说明 ​

1. 先确认是不是「两张表」 ​

2. 为什么会有小写 dump？ ​

3. 不要做的事 ​

4. 已导入库怎么处理 ​

5. 和「static_data 漏导」的区别 ​

涉及代码 / 配置 ​

相关链接 ​

修订记录 ​

问题

答案