1 前言 {#1-%E5%89%8D%E8%A8%80}

由于DataEase 引入了 Flyway 框架，产品研发只需要将版本迭代的数据库更改脚本内容写在 VXX_XX.sql 上，并且按照顺序来命名。DataEase 的后端程序就会一直往下执行，并且在 DataEase v1 版本的数据库中有 dataease_verison 表，v2 版本的数据库中有 de_standalone_version 表，此表会记录下 Flyway 执行在哪一步。执行成功的话会在 success 列上标注 1。所以说，一般报错的状态会是 0。

2 演示出错 {#2-%E6%BC%94%E7%A4%BA%E5%87%BA%E9%94%99}

2.1 新增脚本文本测试 {#2.1-%E6%96%B0%E5%A2%9E%E8%84%9A%E6%9C%AC%E6%96%87%E6%9C%AC%E6%B5%8B%E8%AF%95}

手动新增 V99_9.9.sql 进行测试使用，主要是留意这条语句。

UPDATE V99Test set class = '班级5' WHERE `` = '4';

这是个语法错误，where 后面没有带字段 ，执行肯定会报错，首先咱们先执行一遍。

报错的信息刚好就是说语句有问题，这时候重新回到 dataease_verison 表看下，是否有记载我新写的版本号。

如最初的结论一样，只要 flyway 的版本语句有一处执行失败就会将 success 的状态设置成 0。然后我们再往数据库找下是否有 v99test 的表。

找到了，但是里面没有数据，证明 INSERT 语句并没有执行，或者说 flyway 将这些更改插入操作当做一个事务，只要失败全部就回退。但是创建语句没有回退，导致了数据库就"提前"拥有了这张表。我们将语句补充完整之后，再运行一次 DataEase 后端程序。

Flyway 直接报错 Schema dataease-wei contains a failed migration to version 99 ! 这就是大量用户询问后端执行报错的问题。由于用户之前执行了脚本已经出错或者已经更改过某表结构与我们的脚本语句不同导致出错。

3 解决问题 {#3-%E8%A7%A3%E5%86%B3%E9%97%AE%E9%A2%98}

3.1 情况一 {#3.1-%E6%83%85%E5%86%B5%E4%B8%80}

我们将V99的脚本语句全部复制出来在 navicat 运行下试试看。

完美的执行所有语句，这时候就代表脚本语句已经全部执行，这跟我们后端代码启动执行运用 flyway 执行的效果是一样的。所以说我们可以直接到 dataease_verison 将 V99 的 success 状态由 0 改成 1 ，最后再执行后端程序解决。

3.2 情况二 {#3.2-%E6%83%85%E5%86%B5%E4%BA%8C}

将脚本语句复制到 navicat 运行之后报错，我们就需要找到是哪一行报错，然后通过去更改脚本语句使之成功运行。例如下图报错说表已经存在，这时候就需要将创建表的语句跳过，直接往下执行脚本。

脚本已经全部执行成功，然后再 dataease_verison 找到对应的 99 版本的 success 设置 1 即可。

3.3 情况三 {#3.3-%E6%83%85%E5%86%B5%E4%B8%89}

假如你是自己二次开发修改了某张表的结构，DataEase 新版本恰好更新了这张表的结构。这就会导致研发小哥写的 SQL语句跟你自己二次开发的不一致导致报错，这时候要么你就找到相关语句去修改成符合自己二次开发的结构。要么就直接舍去研发小哥写的内容跳过执行，但是第二种方法是极其不推荐的。