Windows下Informix Client SDK 4.10安装配置与连接排查

简介：Informix Client SDK 4.10 for Windows 面向需要在 Windows 32 位环境下连接和开发 Informix 数据库的开发者，提供 API、驱动与配套文档，帮助完成数据查询、事务处理及客户端配置等任务，并提升应用开发与排错效率。压缩包共 13 个文件，约 176.72MB，以 6 个 txt 说明、3 个 dll 动态库、1 个 properties 配置文件和 1 个 pdf 文档为主，另含 html 与 exe 安装程序，覆盖开发接口、部署组件和参考手册等用途。已有 620 人学习下载，适合具备一定数据库基础、需要搭建 Informix 客户端环境的读者参考使用。包内文档可查阅安装说明、版本发布记录及各语言接口要点，开发者指南与 API 参考涉及嵌入式 SQL、JDBC 访问、错误处理、性能优化和安全设置；properties 配置文件便于理解服务器地址、端口与数据库名等连接参数；动态库和安装程序则支撑应用运行与联调，能帮助读者较快理清 SDK 的组成与使用路径。

1. Informix Client SDK 4.10 与 4.1.0：同一个包，两种叫法

搜informix client sdk 4.1.0的人，十有八九最后拿到手的是 4.10 的安装包，然后对着文件名愣一下：是不是下错了？其实这两个写法指的是同一支产品，4.10 不是 4.1 的第十个补丁，它就是版本号本身的写法，小数点后跟的是两位。这一点没弄清，后面选 32 位还是 64 位、装完为什么 ODBC 管理器里空荡荡、应用为什么一启动就喊找不到 DLL，全都会跟着乱。

这类环境多半出现在老系统边上：一套跑了多年的 ERP 或报表服务还挂在 Informix 库上，换机、扩容、上新应用时，客户端得在新机器上重新装一遍。装顺了半小时的事，装不顺能耗掉一整天，最后连报错信息都看不懂。下面记录的是 Windows 上把 4.10 装完、配好、验证能真正连上库的完整过程。

2. 装前核对：位数、端口、locale 三件事定不下来就别点下一步

动手之前先把三件事钉死，比装完再回头返工划算得多。这三件事分别决定你下哪个安装包、网络能不能通、以及连上之后中文会不会变成问号。我见过太多人是装完了才发现位数不对，卸载重来。

2.1 位数看的是调用方，不是操作系统

最常见的误判是按操作系统选包：机器是 64 位的，就下 64 位。错。Informix Client SDK 4.10 在 Windows 上 32 位和 64 位是两套独立安装包，注册的 ODBC 驱动、装出来的 DLL 也是分开的，判断依据应该是那个要连数据库的进程本身是几位。

一个 32 位的旧报表程序跑在 64 位 Windows 上，它只能加载 32 位的ifx系列 DLL，也只能看到 32 位的 ODBC 驱动。你要是给它装了 64 位客户端，程序启动时就会报「找不到指定的模块」或者 0x7f 之类的加载错误，而命令行里用 64 位工具测试又一切正常，非常迷惑。

拿不准的时候，在那个应用的宿主进程里跑一下这两行，比翻文档快：

# 在目标应用所在的环境里执行,或者直接在应用自己的脚本宿主里跑 [Environment]::Is64BitProcess # 当前进程是 64 位则为 True [Environment]::Is64BitOperatingSystem # 操作系统是 64 位则为 True

第一行是当前进程的位数，第二行才是操作系统。两个值不一致（进程 False、系统 True）就说明你面对的是 32 位应用跑在 64 位系统上，这时候 32 位客户端才是正解。如果一台机器上同时有 32 位和 64 位的应用要连库，那就得两套都装，互不冲突，但要记住它们各自的 DSN 是分开管理的。

另外还要想清楚：是这台机器直接连库，还是经由中间件、应用服务器转发。如果是后者，客户端要装在真正发起连接的那台机器上，装在自己办公电脑上是白费功夫。

2.2 端口通不通，别等装完才发现

Informix 走的是自己的一套监听端口，sqlhosts 里那一列 service name 最终对应的就是这个端口。装之前先用目标机器测一下，能省掉后面大量「到底是客户端配错了还是网络不通」的扯皮。

# 把 10.20.30.40 和 9088 换成实际的库主机地址和 service 端口 Test-NetConnection -ComputerName 10.20.30.40 -Port 9088

重点看输出里的TcpTestSucceeded，True 才算通。如果这里是 False，后面所有配置都不用做了，先找网络或库那边的负责人确认监听地址、端口和访问策略。常见做法是先在一台已经能连库的老机器上查一下它 sqlhosts 里写的端口，照抄过来测，别自己猜。

还要注意库主机监听的可能不是单一地址，有些环境只监听内网某块网卡。用 IP 测通了，就别在配置里改成主机名，避免 DNS 解析绕一圈又出问题。

2.3 locale 对不上，数据全是问号

字符集这一项最容易被跳过。Informix 的客户端有CLIENT_LOCALE和DB_LOCALE两个变量，前者管客户端这一侧怎么解释字符，后者声明你期望连的那个库是什么字符集。两边对不上，轻则中文列显示成乱码，重则连接阶段直接抛出 locale 相关的错误。

问库那边要一个准确的值，或者在能连的机器上查一把：

-- 在已连通的环境里查库的 locale 设置,记下来照抄 select unique dbs_collate, dbs_collate_name from sysmaster:sysdbslocale;

查到的值就是DB_LOCALE该填的东西。常见的组合是纯英文环境用en_US.819或en_US.CP1252，带中文的库用zh_CN.GB18030-2000这类。不确定就先按老机器上的环境变量抄，别自己发明一个。

提示：这三件事最好在开工前写成一行记录贴在工单里——应用位数、库主机端口、库 locale。后面任何一步出问题，先回头看这行记录，能排除掉一半的怀疑方向。

3. 安装 Informix Client SDK 4.10：从 setup.exe 到静默批量的完整过程

安装本身不复杂，复杂的是「装到哪、装哪些组件、装完怎么确认没缺件」。这一步做扎实，后面配置阶段能少踩一半坑。

3.1 目录规划：INFORMIXDIR 定下来就别再改

安装向导会让你指定一个安装目录，这个目录后面会成为环境变量INFORMIXDIR的值，而且会被写进注册表、写进各种配置。装完之后再改目录，等于把整套配置推倒重来，所以第一次就要定好。

我的习惯是不用默认路径，统一放C:\informix。原因很实际：默认路径通常在Program Files下面，带空格，某些老应用在拼接 DLL 路径时对空格处理得很糟糕，排查起来极其费劲。另外路径里绝对不要出现中文，出问题时日志里的路径会变成一堆问号，连错在哪都看不出来。

如果机器上已经装过别的版本，比如老项目留下的 4.50 或者更早的 4.10 补丁包，务必先确认它们装在哪、环境变量指向谁。两个版本共存不是不行，但 PATH 里谁在前谁生效，非常容易搞混。稳妥做法是新版本装到全新目录，用完整的绝对路径去调工具，别依赖 PATH 的顺序。

3.2 图形化安装的点击顺序

以管理员身份运行安装包里的setup.exe，右键「以管理员身份运行」这一步别省，否则写注册表和写系统目录可能失败，装完看起来正常，实际组件缺一半。

向导里的关键几屏是这样：

第一屏是许可协议，接受后进入安装类型选择。这里通常有典型安装和自定义安装两个选项，我一般选自定义，因为典型安装会把一些用不上的组件一起塞进来，而且不一定包含你要的 ODBC 驱动。

组件选择页是重点，至少要勾上这几项：客户端核心文件、ODBC 驱动、命令行工具。如果应用用的是 .NET 提供程序或者 OLE DB，对应组件也要一起勾。这一页没勾的东西，装完之后在 ODBC 管理器里是看不到的，很多人卡在这一步，反复重装同一个包却始终找不到驱动。

接着是安装目录，填C:\informix。再往后是确认页，点安装，等进度条走完。整个过程几分钟，期间不要中途取消，取消后残留的注册表项会让下一次安装报「已存在更高版本」，处理起来很麻烦。

安装日志一般会落在临时目录或者安装目录下的日志文件里。装完如果心里没底，翻一下日志末尾有没有 error 级别的记录，比直接去试连接更主动。

3.3 静默安装：批量部署时的参数

给一批机器装的时候，一台台点向导不现实。Informix 的 Windows 安装包是基于通用安装器封装的，支持响应文件方式静默执行，常见做法是先在一台机器上录一遍响应文件，再拿去批量跑。

:: 第一步:在样机上录制响应文件,按向导正常点完一次 setup.exe /r /f1"C:\pkg\csdk410.iss" :: 第二步:在其他机器上用录好的响应文件静默安装 :: /s 静默 /f1 响应文件路径 /f2 安装日志路径 setup.exe /s /f1"C:\pkg\csdk410.iss" /f2"C:\pkg\install_%COMPUTERNAME%.log"

/r是录制模式，会在你点完向导后把每一步选择写进 iss 文件；/s是静默执行；/f1指定读哪个响应文件；/f2指定日志写到哪。日志名带上机器名，批量跑的时候哪台失败一眼就能定位。

需要提醒的是，不同打包方式的安装器对参数的支持不完全一致，有的版本用/s有的用/quiet。动手前先在测试机上跑一次setup.exe /?看看它自己列出来的参数，别照着别处的文档硬套。响应文件里的安装路径是写死的，如果目标机器盘符不一样，得先改 iss 文件里对应的那一行。

3.4 装完先查这几处，确认没缺件

安装向导说完成，不等于真的装全了。我一般在配置之前先做三个检查，三十秒的事，能挡掉后面很多莫名其妙的错误。

第一，看C:\informix\bin下有没有关键可执行文件，至少应该有命令行工具和几个核心 DLL。目录是空的或者只有寥寥几个文件，说明组件没选对，直接重跑安装程序补组件，别急着重启。

第二，打开 ODBC 数据源管理器，看驱动列表里有没有 Informix 的驱动项。这里有个关键点：64 位系统上 32 位和 64 位的 ODBC 管理器是两个不同的程序，分别位于C:\Windows\System32\odbcad32.exe和C:\Windows\SysWOW64\odbcad32.exe。你装的是哪个位数的客户端，就要去对应的那个管理器里看，去错了地方会以为驱动没装上。

第三，看系统环境变量里有没有被安装程序自动写入的项。有些版本会自动加INFORMIXDIR和 PATH，有些不会。不管加没加，后面我都会按自己的规范重新写一遍，避免出现半自动半手工的混乱状态。

4. 配置三件套：INFORMIXDIR 环境变量、sqlhosts 与 ODBC 数据源

安装只解决了「文件在机器上」，配置才决定「应用能不能连上」。这一章的三部分是有顺序的：环境变量是地基，sqlhosts 是地址簿，ODBC 数据源是给应用看的门牌。

4.1 环境变量：五个值，一个都不能省

Windows 上配 Informix 客户端，核心就是几个变量。用setx写系统级变量，服务账号也能读到，比在「系统属性」里手点更可控。

:: /M 表示写入系统变量,不加 /M 只对当前用户生效 setx INFORMIXDIR "C:\informix" /M setx INFORMIXSERVER "ol_informix" /M setx INFORMIXSQLHOSTS "C:\informix\etc\sqlhosts" /M setx DBTEMP "C:\informix\tmp" /M setx DB_LOCALE "zh_CN.GB18030-2000" /M setx CLIENT_LOCALE "zh_CN.GB18030-2000" /M

逐个说清楚：

INFORMIXDIR是根目录，所有其他路径都可以相对它推导，写错了后面全错。INFORMIXSERVER填的不是主机名，而是 sqlhosts 文件里第一列那个数据库服务器名，这是最容易填错的一个——很多人把 IP 填进去，然后一直连不上。INFORMIXSQLHOSTS指向连接定义文件的完整路径，不写的话客户端会去默认位置找，多版本共存时经常找错。DBTEMP是排序、临时表用的目录，别指向系统盘根目录，也别让它跟其他软件共用。DB_LOCALE和CLIENT_LOCALE按第 2 章查到的值填，两边一般保持一致。

PATH 单独说，因为它有坑：

:: 把 bin 目录放到 PATH 最前面,避免被其他版本抢先命中 setx PATH "C:\informix\bin;%PATH%" /M

%PATH%在命令执行时会被展开成当前值再写回去，所以这条命令重复执行会让 PATH 越来越长，超过 1024 个字符还会被截断，直接把 PATH 写坏。血泪经验是：这条命令一台机器只跑一次，跑之前先把当前 PATH 导出备份一份。

注意：环境变量写完不会影响已经打开的窗口和已经在跑的服务。命令行要新开窗口才生效，Windows 服务必须重启一次才能读到新值。这一点在第 5 章还会再提一次，因为它是「命令行能连、服务连不上」这类问题的头号原因。

4.2 sqlhosts 与 setnet32：同一份连接信息，两种写法

sqlhosts 是一个纯文本文件，每行一条连接定义，四列：数据库服务器名、网络协议、主机名或 IP、服务名。

# dbservername nettype hostname servicename ol_informix onsoctcp 10.20.30.40 infx_9088

第一列ol_informix必须和INFORMIXSERVER的值完全一致，大小写敏感。第二列onsoctcp是最常见的 TCP 协议类型，如果库那边启用了加密，这里会换成对应的 SSL 类型，这个值要问库那边要，不要猜。第三列填 IP 比填主机名稳，少一层解析就少一个故障点。第四列是服务名，不是端口号本身，需要另外定义。

服务名到端口的映射写在 services 文件里：

# 服务名 端口/协议 infx_9088 9088/tcp

这个文件放在C:\informix\etc\services，也可以直接追加到系统的 services 文件里。两处都写也没关系，但别写成不同的端口，否则不同工具可能解析出不同结果。

setnet32是图形化配置工具，在bin目录下，它做的事本质上就是把这些信息写进注册表。打开后重点看两页：Server Information 页填数据库服务器名、主机名、协议名、服务名，跟 sqlhosts 那四列一一对应；Environment 页可以覆盖INFORMIXDIR、INFORMIXSERVER这些值。

这里的选择是：要么用 sqlhosts 文件，要么用 setnet32 写注册表，尽量别两边都配。两边都配且值不一致时，哪个生效取决于客户端版本的查找顺序，出问题时你会陷入「文件里明明是对的」的自我怀疑。我一般统一用 sqlhosts 文件，因为它是文本，能进版本库，换机器直接拷过去，比逐个点图形界面可靠。

如果确实要用 setnet32，注意 64 位系统上注册表有重定向，它写入的位置可能落在 32 位视图下，而 64 位应用读的是另一处。装的是 64 位客户端却用 32 位的 setnet32 去配，就会出现「配了但没生效」的现象。

4.3 ODBC 数据源：在对应的 odbcad32 里建 DSN

驱动装好了、sqlhosts 配好了，最后一步是给应用一个能直接引用的入口，也就是 DSN。打开对应位数的 ODBC 数据源管理器，切到「系统 DSN」选项卡——选系统 DSN 而不是用户 DSN，是因为 Windows 服务跑在别的账号下，读不到你个人账户的用户 DSN。

点添加，在驱动列表里选中名字包含 INFORMIX ODBC DRIVER 的那一项，然后按下面这些项填：

填完点「测试连接」，会提示输入密码。这一步过了，说明驱动、网络、认证三层都是通的。过不了也别急着改，先看报错码，第 5 章按错误码分了类。

如果应用不是通过 DSN 而是走无 DSN 连接串，那 DSN 可以不建，但连接串里的 Server、Host、Service、Protocol 四项还是要齐，填的值跟上面这张表一模一样。少了任何一项，报出来的错通常会指向认证失败，很容易误导方向。

最后提醒一句账号的事：不要用个人账号做应用连接。这在任何环境里都成立，但在这种老系统上尤其致命，因为改密码的流程往往没人维护，等哪天连接突然全断，才发现是某个人改了密码。

5. 排查清单：装完连不上的五种典型现象

配置做完之后，最耗时间的不是装，是「明明每一步都照做了，就是连不上」。下面这几条是我这些年反复遇到的，按现象、原因、解决三段记，遇到问题先在这里对号入座，能省掉大量试错。

5.1 现象：ODBC 管理器里根本看不到 Informix 驱动

打开 ODBC 数据源管理器，驱动列表里翻遍了也没有 Informix 相关的项，但安装程序明明提示成功了。

原因通常有两个。一是打开的管理器位数不对，装的是 32 位客户端却打开了 64 位的odbcad32.exe，两边看到的驱动列表是各自独立的，互相看不见。二是安装时在组件选择页没勾 ODBC 驱动那一项，只装了核心文件，这种情况下bin目录里有 DLL，但驱动没注册。

解决办法是先分别打开两个管理器确认：从C:\Windows\System32\odbcad32.exe进的是 64 位视图，从C:\Windows\SysWOW64\odbcad32.exe进的是 32 位视图，两个都看一遍，确定驱动到底注册在哪个视图下。如果两边都没有，重跑安装包，在组件页把 ODBC 驱动勾上。重装前不需要卸载，安装程序会识别已有组件做增量安装。

还有一种少见情况：驱动文件在，但注册表项被安全软件拦了。这种一般能在安装日志里看到注册表写入失败的记录，把安装目录和安装程序加进白名单再跑一次即可。

5.2 现象：应用一启动就报找不到 DLL，命令行测试却正常

典型表现是应用弹窗报「无法加载 DLL」或者「找不到指定的模块」，错误码可能是 126、193 或者 0x7f，但你在同一台机器上开个命令行跑客户端自带的工具，连库一切正常。

这是位数不匹配的标准症状。64 位进程只能加载 64 位 DLL，32 位进程只能加载 32 位 DLL，操作系统层面就拦住了，跟配置对不对没关系。命令行工具能跑，是因为你跑的那个工具恰好和已安装的客户端位数一致。

解决分两步。先确认应用进程的位数，用第 2 章那两行 PowerShell 命令。再确认已安装客户端的位数，看bin目录下 DLL 的实际情况，或者看它注册在哪个 ODBC 视图下。两边不一致就补装另一个位数的客户端，装到不同目录，两套可以共存。

补装之后要注意 PATH。两个版本的bin都在 PATH 里时，谁在前面谁先被找到。我的做法是不依赖 PATH 做版本区分，而是在应用自己的启动脚本里显式把对应版本的bin目录放到最前面，这样每个应用用哪个版本一目了然，不会互相干扰。

5.3 现象：网络通、端口通，连接时报 -908 或 -930

用端口测试工具测是通的，但一发起数据库连接就失败，报错里带 -908 或者 -930 这类负号数字。

这类错误码基本都指向连接定义本身有问题，而不是网络。最常见的是 sqlhosts 里的服务名在 services 文件里找不到对应条目，客户端拿到一个名字却不知道往哪个端口发。其次是主机名解析失败——sqlhosts 第三列写的是主机名，而这台机器解析不了这个名字。第三种是 sqlhosts 里第一列的服务器名和INFORMIXSERVER的值不一致，差一个字母都不行。

排查顺序是：先把 sqlhosts 第三列的主机名换成 IP，排除解析问题；再核对第一列和INFORMIXSERVER是否逐字符一致；最后检查 services 文件里有没有对应的服务名条目，没有就补一行，格式是「服务名 端口/tcp」。

提示：改完 sqlhosts 或 services 之后，不需要重装也不需要重启机器，但已经打开的命令行窗口和新起的进程要重新读文件，改完新开窗口再测。

还有一种情况是服务名和端口对上了，但库那边监听的不是这个地址。这种从客户端这边查不出来，需要让库那边确认监听配置。

5.4 现象：能连上，但中文全是问号或者报 locale 错

连接本身成功，能执行查询，但中文字段显示成乱码，或者直接报 locale 相关的错误，错误信息里带 -23101 之类的编号。

原因就是CLIENT_LOCALE和DB_LOCALE跟库的实际字符集对不上。这两个值不是随便填一个「看起来像中文」的就行，必须是库那边真实支持的字符集名称。填了一个库不认识的值，客户端在建立会话阶段就会失败。

解决办法是先查库的实际 locale，用第 2 章那条查sysdbslocale的语句，把查到的dbs_collate值原样填进DB_LOCALE。CLIENT_LOCALE一般跟它保持一致，除非应用侧有明确的转换需求。

改完之后记得重启应用进程，环境变量对已运行的进程不生效。如果应用是以服务方式跑的，要重启服务，光重启命令行没用。

5.5 现象：命令行能连，装成 Windows 服务就连不上

同一台机器，同一个账号，命令行里跑工具连得好好的，把应用注册成 Windows 服务之后连不上，日志里报环境变量找不到或者连不上库。

这是环境变量作用域的问题。用setx不加/M写的是当前用户变量，只对你登录的账户可见；Windows 服务通常跑在LocalSystem或者某个服务账号下，读不到你的用户变量。同理，你在图形界面里配的用户级环境变量，服务同样看不到。

解决办法是把所有相关变量都用/M写到系统级，写完重启服务让新进程读到新值。如果服务是用特定账号跑的，还要确认这个账号对INFORMIXDIR目录和DBTEMP目录有读写权限，权限不足时报的错往往也是「连接失败」，很容易往网络方向查。

还有一点容易忽略：服务启动时读取的环境变量是注册表里的值，不是当前命令行窗口里的值。在窗口里set一下临时变量再启服务，是不生效的。

6. 验证跑通：用 dbaccess、ODBC 和应用三层确认

装完配完，别急着交给业务方，按三层验一遍，每层都过了才算真的跑通。这三层是从底往上排的：底层通不通、驱动层通不通、应用层通不通，任何一层挂了都能立刻定位到范围。

第一层，用客户端自带的命令行工具直接连库，这一层绕开 ODBC，验证的是 sqlhosts、网络和认证。

:: 连到 sysmaster 库,数一下系统表的条数,能出数字就说明会话建立了 echo select count(*) from systables; | dbaccess sysmaster -

能返回一个数字，说明INFORMIXDIR、INFORMIXSERVER、INFORMIXSQLHOSTS三个变量和 sqlhosts 文件都是对的。这一层失败，问题一定在配置或网络，不用往应用上想。

第二层，走 ODBC 通道验证，验证的是驱动注册和 DSN 配置。

# 用 DSN 建连接,执行一条最简单的查询 $conn = New-Object System.Data.Odbc.OdbcConnection $conn.ConnectionString = "DSN=infx_demo;UID=appuser;PWD=******;" $conn.Open() $cmd = $conn.CreateCommand() $cmd.CommandText = "select count(*) from systables" $cmd.ExecuteScalar() $conn.Close()

ConnectionString里的DSN换成你实际建的名字，用户名密码用应用账号。如果这一步报「未找到数据源名称」，说明位数又对不上了——PowerShell 本身是 64 位的，它只能看到 64 位 DSN，32 位 DSN 要用 32 位宿主去测。

第三层，让真正的应用跑一次它自己的功能，比如打开一张报表、执行一次同步任务。这一层过了，才算交付。

三层的对应关系整理成一张表，出问题时按表定位：

三层都过完之后，我还会做一件事：把INFORMIXDIR下的 sqlhosts、services 和所有环境变量值导出一份文本，跟应用配置一起归档。换机器的时候照这份文件重建，比凭记忆点一遍快得多，也不会漏项。

从那以后我每次装这类客户端，都强制自己先做完第 2 章那三项核对再动手，宁可多花十分钟确认位数和 locale，也不愿意装完再回头卸载。这套流程救过我很多次，希望帮到你。

本文还有配套的精品资源，点击获取