dimp时报错，字符串截断

现象描述

达梦也有自己的逻辑备份工具（dexp 、dimp ）用法和Oracle 类似，详细用法可以参考官方手册dexp&dimp.pdf

博罗ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联建站的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18980820575（备注：SSL证书合作）期待与您的合作！

但是，我们有时候在进行dimp 时，会碰到字符串截断的问题。

碰到这种问题，我们怎么解决呢？

受限我们一定要非常明确，字符串截断这个报错，一定就只是精度不足，这里只是针对两种可能的情况的，描述下该问题。

只需要考虑两个问题：

Ø   是否表结构不一致，就是dexp 的表，是varchar （500 ），我们导入的表只是varchar （400 ）

这种情况少，因为有时候我们经常是全用户新建导入，表结构也是源端带入过来的。

Ø   Dexp 源端的数据库实例字符集，是否和dimp 目的端数据库实例的字符集一致

这个是我们可能没有注意的问题。

处理方法

处理方法一：核查表结构是否一致

是否表结构不一致，就是dexp 的表，是varchar （500 ），我们导入的表只是varchar （400 ）

这个问题好理解，就是字面意思，我们只需要把目的表的精度改成和源端一致，重新清空目的表，再导入即可。

处理方法二：核查数据库实例字符集

我们碰到这个问题的时候，实际上就是我们从UTF-8 的数据库实例上dexp 出来的数据库，往GB18030 的数据库实例上dimp ，才会碰到这个问题。

默认情况下，达梦数据库实例的varchar 字段的精度，表示的含义是字节，而对于汉字而言，在UTF-8 编码下的字节占用，是比GB18030 编码下的字节占用，要大。

所以反过来说，对于dexp&dimp 搬过来的表结构，都是一致的情况下，比如：都是varchar （400 ），可以存放的汉子个数，是不一样的。

备注：

-           对于同一项目内的数据库实例、可能需要互相进行数据传递的实例之间，务必把数据库底层参数（含字符集）规划并切实设置成一致！

-           同一项目内的数据库实例，请务必保持一致、非同一项目内，有数据传递需求，但是相关性不搞，且确实不能保持一致的字符集，可以通过手动放大目的端数据库实例上的varchar 字段精度。为什么可以这样处理，方法二中已经说明。

这是一个把数据库实例中目标表中的所有varchar 字段，精度放大一倍的脚本（当成SQL 执行）：通过控制游标查出来的表即可。

declare begin for rs in( select sch.name sch,tab.name tab,col.name   col,COl.length$ len from sysobjects sch,sysobjects tab ,syscolumns col where sch.id=tab.schid and   sch.name||'.'||tab.name in ( 'USER.TABUTKMONITOR', 'USER.TABUTHORIZATIONRISKLOG', 'USER.TABUSTOMER', 'USER.TABARD', 'USER.TABOSSREPORT', 'USER.TABUDGETENTITYCARDS', 'USER.TABRANSACTIONLOG', 'USER.TABCCOUNT', 'USER.TABSTOMERINFO', 'USER.TABRANSACTIONLOG', 'USER.TABUTHORIZATIONRISKLOG' ) and tab.id=col.id and col.TYPE$ in   ('VARCHAR','VARCHAR2') ) loop declare begin  execute immediate 'alter table   "'||rs.sch||'"."'||rs.tab||'" modify '||rs.col||'   varchar('||rs.len*2||');'; exception when others then  print(sqlerrm); end; end loop; end;

当前文章：dimp时报错，字符串截断
本文来源：http://scjbc.cn/article/gghpos.html