DB2绑定问题（-818）

sunlan

最近在帮客户开发财税库银联网系统，中间用到了DB2。具体的应用环境如下：
  版本 8.2
  平台 Redhat Linux AS4 U3(32bit)
  开发方式 ESQL/C

目前遇到的问题如下：
在程序重新编译执行时报818错。经反复检查，确认bind文件已坐绑定。更怪的现象如下：
假定将所有的bind文件、.o文件删除后重新编译，新生成的bind文件有tipsp9100.bnd、tipsp9106.bnd、tipsp9102.bnd等。我当前要测试的代码模块涉及的bind文件为tipsp9100.bnd，该文件的bind时间早于其它的几个文件。在执行时，数据库报818错。然后，重新绑定tipsp9100.bnd，在执行程序测试，一切OK。测试通过后，再随便绑定一个bind文件（例如tipsp9106.bnd），再次执行程序测试，又报818错。再此测试过程中均未重新编译代码，仅是对bind文件按不同次序重新绑定。

其它模块是否受绑定的次序影响目前还没有做进一步测试。

有谁遇到过类似的问题或有解决的办法？

sunlan

找到原因了！是由于文件名称过长了！
考虑到便于代码管理，我将程序都以tipsp打头、后面带4位的业务代码，合计9位。而DB2在进行预编译产生bind文件时自动将package的名称截为8位。下面是DB2帮助里对于package名称的说明：
By default, each package is given a name that is the same as the name of the source module from which the .bnd file originated, but truncated to 8 characters. To explicitly specify a different package name, you must use the PACKAGE USING option on the PREP command.
实际上，只要源程序文件名称长度大于8位，无论是否显示地指定包的名称都不会有什么用处——因为在DB2数据库已限定了内部存储的packege名称最长只能是8位！（见 SQL Limits，Longest unqualified package name）。因此，所有前8位相同的源程序进行预编译后只有最后产生的package文件是有效的，其它的都会在执行的时候产生818错。
DB2的这种实现机制，给源代码命名带来了很大的限制。在开发过程中务必要注意！

pjj0618

呵呵，楼主自己找到问题，好事情～

Lovedfox

我也遇到这个问题，也是这个原因！:wink: