Question

我正在运行一个Java应用程序，它将我需要导入的文件传输到DB2所在的服务器。然后Java应用程序创建与数据库的JDBC连接并运行：

 CALL SYSPROC.ADMIN_CMD('import from <filename> of del modified by decpt, coldel; messages on server inert into <view>')

我遇到的问题似乎某种程度上与数据库用于导入文件的用户数据库的charset相关（使用admin_cmd存储过程）。那个问题是： “Umlaute”，就像ä，ö，ü被这个导入搞砸了。我过去遇到过这种问题，解决方法始终是将用户的LC_CTYPE设置为de_DE.iso88591

我已经排除了问题的根源： - 文件传输到数据库服务器。（之后，合唱团仍然可以） - JDBC连接（我只是通过sql命令插入一行而不是从文件中读取）

问题是我现在不知道用户DB2通过ADMIN_CMD导入文件的用户。而且我也不相信它可以以某种方式连接到DB2设置，因为使用其他方式插入，加载...数据，everthing工作正常。

是的，我需要使用ADMIN_CMD。 DB2命令行工具是一场性能噩梦..

Answer 1

最好的方法（为了理智）：

将所有数据库创建为UTF-8
确保所有操作系统区域设置均为UTF-8
摆脱所有不处理UTF-8数据的应用程序
屠杀每个不遵守UTF-8的开发商和供应商。重复并冲洗至100％完成。

DB2确实attempts to be smart并为您转换输入数据（import命令基本上将您的数据传输到insert子句中 - 总是得到这样的处理）。我给出的链接将概述基本原理，并提供一些命令来试用。此外，有类似的official explanation。根据它，您可以尝试设置环境变量 db2codepage 以与您的分隔数据文件相对应，这应该会有所帮助。此外，IXF格式导出可能更好，因为它们在每个文件中附加了编码相关信息。

Answer 2

感谢您的回复。

我最后通过添加

解决了这个问题

MODIFIED BY CODEPAGE=1252

到我的JDBC - ADMIN_CMD导入命令。这似乎覆盖了db之前使用的任何代码页设置。它似乎也是数据库的默认代码页无关紧要，因为它设置为1252.我现在唯一可以想到的是所有这一切的原因可能是DB2在通过ADMIN_CMD导入时使用的linux设置。 / p>

使用DB2 SYSPROC.ADMIN_CMD进行数据库导入时，Characterset存在问题

2 个答案: