企业官网建设流程全解析

简介：面向 Windows 32 位平台的 Informix 客户端开发套件，适合需要使用 C、C++、Java 等语言连接 Informix 数据库的开发者、运维人员与数据库应用维护者。它提供 API、驱动与开发文档，可用于构建、调试和维护数据库交互程序，并帮助理解客户端连接参数配置与 OAT 在线应用传输相关管理场景。压缩包共 13 个文件，约 176.72MB，包含 6 个 txt 说明、3 个 dll 动态库、1 个 properties 配置文件、1 个 pdf 文档、1 个 html 页面及 1 个 exe 安装程序，覆盖安装、接口调用、连接配置与开发参考等用途。已有 620 人学习，适合作为 Informix 客户端环境搭建与开发查阅的配套资料。读者可从中获得 SDK 安装入口、客户端连接配置思路、Java 访问接口相关资料，以及安装指南、版本说明和开发文档，便于排查连接与兼容性问题，并为基于 Windows 32 位环境的 Informix 应用开发提供参考。

1. 先分辨版本号：4.10 与 4.1.0

搜索 informix client sdk 4.1.0 的人，八成会先卡在版本号上——安装包文件名写的是 4.10，读作“四点一零”，属于 4.x 系列的一个维护级别，不是把 4.1 后面多加个零。我见过有同事照着 4.1.0 去找补丁包，翻了一下午也没对上号。这个 Windows 客户端 SDK 里装的是 ESQL/C 预编译器、ODBC 驱动、.NET 数据提供者和 dbaccess、setnet32、finderr 这几个命令行工具，作用是让 Windows 上的程序连上远端那台还在跑的 Informix 实例。适合两类人：一类是维护存量系统、被要求“先让它连上”的后端和运维，另一类是要从老库里把数据抽出来做报表、做同步的开发者。

2. 解压安装包：目录结构和选哪个版本安装

拿到安装包先别双击运行，解压看目录结构，比看任何说明文档都快。这里面有两个判断要做：装哪个版本、装哪些组件。判断错了，后面所有排错都可能白费力气。

2.1 安装完成后 %INFORMIXDIR% 里各目录的作用

CSDK 装完后的根目录习惯上叫%INFORMIXDIR%，我一般固定在C:\informix\csdk410，路径不带空格、不带中文，省掉一堆引号问题。对照下面这张表浏览一遍，后面出错时你就知道该去翻哪儿。

bin目录是整个 SDK 的核心。esql.exe本身不是编译器，它是个包装器，负责把.ec里的EXEC SQL语句翻译成 C，再调用 MSVC 编译链接，所以机器上必须先有编译环境，光装 SDK 是编不出 exe 的。finderr -908这类命令能把数字错误码翻译成人话，比在网上搜“-908 是什么”准得多。

2.2 32 位和 64 位：装错版本的代价

这是最容易出错的地方，也是我踩过的最大的坑。Windows 上 32 位和 64 位程序读取的是两套完全独立的 ODBC 数据源注册表分支，32 位驱动装进去，64 位进程照样报“未找到数据源名称且未指定默认驱动程序”，反过来也一样。判断方法很简单，看调用方进程的位数：IIS 应用池、Windows 服务、你自己的 exe，位数是多少就装哪个版本。

提示：C:\Windows\System32\odbcad32.exe是 64 位数据源管理器，C:\Windows\SysWOW64\odbcad32.exe才是 32 位的。两个文件名一模一样，只能靠路径区分。

如果一台机器上同时有 32 位老程序和 64 位新程序，那就两个包都装。两个版本可以共存，只要PATH里的顺序和 ODBC 驱动名不打架。实际操作中我会把 64 位装在C:\informix\csdk410，32 位单独装到C:\informix\csdk410_x86，避免覆盖。

2.3 组件选择：只装运行时和全装的区别

安装器会问你要装哪一套：Client（运行时）、Client + 开发组件、Server 相关。判断标准只有一个：这台机器上有没有人写代码。

只跑现成程序的服务器，选最小集，有 ODBC 驱动和运行库就够了；要编译.ec或者引用IBM.Data.Informix.dll的开发机，必须把开发组件带上，否则esql找不到头文件，报一堆Cannot open include file: 'sqlca.h'。我在测试机上偷懒选过最小集，结果花了半小时才反应过来少装了incl目录，这种坑重复出现的概率很高。

另外提一句：这套 SDK 的部署授权有明确条款，商业分发前请自己核对随包附带的许可文件，别想当然地以为客户端可以随便打包进安装程序。

3. 实际安装与环境变量：把连接信息放对地方

安装这一步本身不难，麻烦的是装完之后的环境变量和连接信息配置。Windows 上 CSDK 的连接信息有两个地方：注册表里的setnet32配置，和sqlhosts文件。两个都可以用，但我一律用文件，理由后面讲。

3.1 静默安装与响应文件

给一台机器装是点鼠标，给二十台机器装就得靠命令行了。CSDK 的 Windows 安装器是 InstallAnywhere 那一套，支持录制响应文件再回放。

:: 1) 先跑一遍图形安装，把参数录成响应文件 :: -r 表示 record，交互走完之后参数会写进指定文件 installclientsdk.exe -r "C:\temp\csdk410_resp.properties" :: 2) 打开响应文件，把安装路径改成统一值，比如 USER_INSTALL_DIR=C:\\informix\\csdk410 :: 注意 Windows 路径在属性文件里通常要写成双反斜杠 :: 3) 用响应文件静默安装，适合批量刷机 installclientsdk.exe -i silent -f "C:\temp\csdk410_resp.properties" :: 4) 检查退出码，0 才算成功；非 0 时去 %TEMP% 找安装日志 echo %ERRORLEVEL% :: 5) 装完确认关键可执行文件都到位 dir "C:\informix\csdk410\bin" | findstr /I "esql dbaccess setnet32 finderr"

参数说明：-i silent是静默模式开关，-f后面跟响应文件路径。响应文件里的属性名各小版本会有出入，所以不要手写，一定要用-r录制出来的那份作模板改，这样最稳。静默安装失败的日志一般落在%TEMP%下以安装包名开头的 log 文件里，ERRORLEVEL是 1 或者 2 的时候，先看日志最后 30 行，常见原因是路径含中文、磁盘权限不足、上一个版本没卸干净。

注意：静默安装不会帮你配置环境变量，装完只是文件到位了，第 3.3 节的活还得手动做。

3.2 setnet32 与 sqlhosts：连接信息写在哪里

setnet32.exe是个图形小工具，填主机名、服务名、协议、用户名，写进注册表HKEY_LOCAL_MACHINE\SOFTWARE\Informix下面。它能用，但有两个毛病：一是机器迁移、克隆的时候注册表项容易丢；二是多套环境（测试、生产）切来切去的时候，改注册表要管理员权限，改完还得重启程序才生效。

所以我一般走文件路线。sqlhosts就是一个纯文本文件，每行一条连接定义，格式是服务名 协议 主机名 服务端口：

:: 把连接信息落到文件而不是注册表，迁移和审计都方便 set INFORMIXDIR=C:\informix\csdk410 set INFORMIXSERVER=demo_on set INFORMIXSQLHOSTS=C:\informix\csdk410\etc\sqlhosts set PATH=%INFORMIXDIR%\bin;%PATH% :: 一行一个服务名：demo_on onsoctcp 10.0.0.21 9088 echo demo_on onsoctcp 10.0.0.21 9088>> %INFORMIXSQLHOSTS% :: 冒烟测试：先确认能登上，再确认能取数 (echo select count(*) from systables;) | dbaccess demo@demo_on -

第一列demo_on是服务名，必须和INFORMIXSERVER环境变量完全一致，大小写在部分版本上是敏感的，别随手改成大写。第二列onsoctcp是最常用的 TCP/IP 协议族，老文档里写作ontlitcp的是另一套。第三、四列是数据库主机和服务端口，端口要和服务器端sqlhosts里定义的一致，默认常见是 9088，但生产环境基本都会改，这一点别猜，找服务端要。最后那句dbaccess是登进去执行一条最简单的查询，能返回一个数字就说明链路通了；报-908就是连不上，报-23101就是区域设置对不上。

3.3 环境变量清单：服务账号读的是系统级

环境变量这一块，最隐蔽的坑是“我用管理员账号跑得好好的，做成服务就起不来”。原因很简单，Windows 服务、计划任务用的是系统级环境变量或者服务账号自己的用户变量，你在自己登录会话里set的那些，服务一个都看不见。

配置顺序上，PATH一定要把 CSDK 的bin放在最前面。机器上如果装过旧版客户端，或者某些 ERP 自带了一份老iclit*.dll，PATH顺序错了就会加载到旧库，报错信息往往莫名其妙。设好之后开一个新的 cmd 窗口，用set INFORMIX确认一遍，别在老窗口里试——环境变量不会热更新，这也是很多人“改了没生效”的真实原因。

4. 三种连接方式跑通：ODBC、ESQL/C、.NET

连通性验证不要只测一种。ODBC 通了不代表 ESQL/C 能编，ESQL/C 编出来了也不代表 .NET 那头能跑，因为三者依赖的库不完全是一套。下面三条路我都按“最小可跑”的方式写，跑通了再往业务代码里套。

4.1 ODBC：驱动名、连接串和一段验证脚本

头号失败原因是驱动名写错。驱动名不是“Informix”三个字，而是一长串带版本号的东西，不同版本还不一样。先查清楚本机注册了什么，再写连接串。

# 列出本机已注册的 ODBC 驱动，驱动名对不上是连接失败的头号原因 Get-OdbcDriver | Where-Object { $_.Name -like "*INFORMIX*" } | Select-Object Name, Platform # DSN-less 连接串：没有数据源也能连，省掉配置数据源的环节 $cs = "Driver={IBM INFORMIX ODBC DRIVER (64-bit)};Host=10.0.0.21;Server=demo_on;" + "Service=9088;Protocol=onsoctcp;Database=demo;UID=app;PWD=***;" $cn = New-Object System.Data.Odbc.OdbcConnection $cs $cn.Open() (New-Object System.Data.Odbc.OdbcCommand "select today from systables where tabid=1", $cn).ExecuteScalar() $cn.Close()

逻辑说明：Get-OdbcDriver在 Windows 8 和 Server 2012 以后才有，老系统就用注册表HKLM\SOFTWARE\ODBC\ODBCINST.INI\ODBC Drivers下面找。连接串里Host是数据库主机 IP，Server是服务名，Service是端口，这三个必须和服务端sqlhosts里的定义一一对应，缺一个就报-908。Database是库名，不是服务名，写错了会得到另一个错误码。

这个脚本能跑通，说明 64 位 ODBC 这一层没问题。但如果你用New-OdbcDsn或者图形面板建了用户 DSN，而程序是以服务身份跑的，一样会失败——用户 DSN 只对当前登录用户可见。生产环境我一律用系统 DSN 或者干脆 DSN-less，少一层依赖少一个故障点。

4.2 ESQL/C：预编译、编译、链接三步

.ec文件不能直接交给 C 编译器，得先过esql。这条路最容易被忽视的前置条件是：必须先有 MSVC 环境，esql只是把EXEC SQL翻译成 C 再调用cl.exe。

/* demo.ec —— 最小可跑：连库、取一行、断开 */ #include <stdio.h> EXEC SQL include sqlca; /* sqlca 里有 sqlcode，错误判断全靠它 */ int main(void) { char tabname[129]; EXEC SQL connect to 'demo@demo_on' user 'app' using 'pwd'; if (sqlca.sqlcode < 0) { /* 连不上先看这个数字，用 finderr 翻译 */ printf("connect failed: %d\n", sqlca.sqlcode); return 1; } EXEC SQL select tabname into :tabname from systables where tabid = 1; printf("first table: %s\n", tabname); EXEC SQL disconnect current; return 0; }

编译命令：

:: esql 是包装器，先有 MSVC 环境，否则报找不到 cl.exe call "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvars64.bat" :: -o 指定输出文件名；-g 带调试符号；-thread 编线程安全版本；-static 静态链接 esql -g -o demo.exe demo.ec :: 跑一遍，连库失败会打印负数错误码 demo.exe

参数含义：-o后面是产物名，-g只在排错期加，-static会把客户端库静态链进去，好处是目标机不用装 SDK，坏处是包体积变大、升级要重编。我一般开发阶段用动态链接方便替换库，上线打包再评估要不要静态。如果esql报Cannot open include file: 'sqlca.h'，八成是INFORMIXDIR没设或者incl目录缺失，先把环境变量确认一遍再怀疑代码。

4.3 .NET：引用 IfxClient 并注册数据提供者

.NET 这条路依赖%INFORMIXDIR%\bin\netf40\IBM.Data.Informix.dll，直接把 dll 拷到项目里引用也行，但要注意位数：AnyCPU 的进程在 64 位系统上默认按 64 位跑，引用的必须是 64 位那套 dll，否则运行时报BadImageFormatException。

// 引用 %INFORMIXDIR%\bin\netf40\IBM.Data.Informix.dll using IBM.Data.Informix; using System; class Program { static void Main() { // 和服务端 sqlhosts 里的定义保持一致，Host/Server/Service 三件套别写错 var cs = "Host=10.0.0.21;Server=demo_on;Service=9088;Protocol=onsoctcp;" + "Database=demo;User ID=app;Password=***;"; using (var cn = new IfxConnection(cs)) { cn.Open(); using (var cmd = new IfxCommand("select count(*) from systables", cn)) Console.WriteLine("tables: " + cmd.ExecuteScalar()); } } }

类名前缀是Ifx，不是IfxConnection之外的Odbc那一套，混用会编译不过。如果项目里用了DbProviderFactories.GetFactory("IBM.Data.Informix")这种按名称取工厂的写法，还需要在machine.config里注册 provider，这一步经常被漏掉，报错信息是“未找到指定的提供程序”。我的习惯是能用连接字符串直连就别走工厂注册，少一个全局配置文件，部署时少一处要改。

5. 避坑与排查：五个真实现场

错误码是这套东西的黑匣子，finderr能翻译大半，但有些坑它翻译不出来，因为根本不是数据库报的错，是 Windows 层面的问题。下面五条都是我在实际环境里碰到的，按“现象 → 原因 → 解决”记一遍，能省掉不少时间。

第一坑：64 位程序报“未找到数据源名称”现象：程序是 64 位的，用odbcad32.exe建了系统 DSN，连接串里也写了 DSN 名，照样报错。原因：你打开的是System32下那个 64 位管理器，但建 DSN 时实际选的是 32 位驱动，或者反过来，驱动本身没注册到对应分支。解决：先Get-OdbcDriver看 Platform 列，确认驱动位宽；再确认建 DSN 用的管理器和程序位宽一致。最省事的办法是干脆不用 DSN，DSN-less 连接串直接指定 Driver 名。

第二坑：PATH里有旧版客户端，报 DLL 版本不匹配现象：同一份代码在测试机跑得好好的，到生产机上报错，错误信息里提到某个iclit或者isqlt开头的 dll。原因：生产机装过别的系统，PATH里排在前面的目录带了一份老版本客户端库，先被加载了。解决：set PATH看清楚顺序，把%INFORMIXDIR%\bin提到最前；用进程监视工具确认实际加载的 dll 路径。改完必须开新窗口，老窗口的环境变量不会刷新。

第三坑：能 ping 通但连不上，报-908现象：ping主机是通的，dbaccess报-908，等十几秒才返回。原因：主机通不代表数据库端口通，中间可能隔着防火墙或者端口映射，也可能是服务名和端口写错。解决：先用Test-NetConnection 10.0.0.21 -Port 9088确认端口可达；不可达就找网络那边开端口；可达但仍报错，就用finderr -908看具体说明，再核对sqlhosts里的协议和服务名。设置INFORMIXCONTIME=10能让失败快点返回，别干等。

第四坑：中文乱码，报-23101现象：查询能过，但返回的中文是问号或者乱码，或者干脆报区域设置相关的错误。原因：客户端CLIENT_LOCALE或DB_LOCALE与数据库实际使用的字符集不一致。解决：先问清楚库的字符集（dbaccess里查系统表能看到），然后把DB_LOCALE设成一致的值，CLIENT_LOCALE按程序实际输出需要配。两个变量不是随便设一个就行，配错了比不配还麻烦，因为不配时至少不报错。

第五坑：做成 Windows 服务就起不来现象：命令行里跑得好好的程序，注册成服务之后启动失败，日志里说连不上库。原因：服务账号读的是系统级环境变量，你在自己会话里设的用户级变量它看不见。解决：把INFORMIXDIR、INFORMIXSERVER、INFORMIXSQLHOSTS、PATH全部配到系统级，配完重启服务。另外服务账号一般没有网络访问权限的限制，但网络驱动器映射是看不见的，INFORMIXSQLHOSTS千万别指向网络路径。

6. 上线前用一页清单验一遍

装完、连上、跑通，这三件事做完还不算完，真正让人放心的是“换台机器能不能重来一遍”。我现在的习惯是，交付前把关键信息落成一页清单，同时用一段脚本把环境探一遍，把结果贴进交付单。这样半年后别人接手，或者自己回头查，不用靠回忆。

下面这段脚本我会放在部署包的check.ps1里，每次换机器先跑它，比人工核对快得多：

# 一键摸清本机 CSDK 环境，输出直接贴进交付单 $dir = $env:INFORMIXDIR "INFORMIXDIR = $dir" "INFORMIXSERVER = $env:INFORMIXSERVER" "INFORMIXSQLHOSTS = $env:INFORMIXSQLHOSTS" if ($dir) { # 版本号藏在可执行文件的文件信息里，比猜文件名可靠 (Get-Item "$dir\bin\esql.exe").VersionInfo.FileVersion # 打出所有已注册的 Informix ODBC 驱动及其位宽 Get-OdbcDriver | Where-Object { $_.Name -like "*INFORMIX*" } | Format-Table Name, Platform -AutoSize } else { "环境变量未设置，先跑一遍系统级配置" }

这里有个我吃过亏的细节：别用文件名判断版本，esql.exe的版本信息才准。曾经有一次两台机器目录名一模一样，实际一个是 4.10 一个是更老的版本，靠肉眼根本分不出来，最后是比对 FileVersion 才定位到。还有个小技巧，如果目标机器不方便跑安装程序，可以把整个%INFORMIXDIR%目录打包拷过去，配好环境变量就能用，这套 SDK 基本是绿色的——但注册表里的 ODBC 驱动信息拷不过去，所以 ODBC 那条路仍然得走安装器，ESQL/C 和 .NET 直连则可以省掉安装。

从那以后我每次交付前都强制走一遍这份清单，哪怕只是“换个机器再装一次”这种看起来毫无风险的操作。老系统的坑不在于难，而在于它总在你以为稳了的时候冒出来。希望帮到你。

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