企业官网建设流程全解析

简介：这份 Informix Client SDK 4.10 for Windows 面向在 Windows 32 位环境中开发、维护 Informix 数据库应用的开发者与运维人员，提供客户端驱动、编程接口及配套文档，用于解决应用连接数据库、执行 SQL 与事务处理等基础问题。压缩包共 13 个文件，约 176.72MB，包含 6 个 txt 发布说明、3 个 dll 运行库、1 个 properties 连接配置、1 个 pdf 安装文档、1 个 html 说明页和 1 个 exe 安装程序，兼顾部署与查阅。目前已有 620 人学习下载。读者可据此了解 C/C++、Java 等语言的访问方式，掌握 JDBC、嵌入式 SQL、JAB 等接口的使用思路，并结合 csdk.properties 理解服务器地址、端口与数据库名的配置关系；文档部分还能帮助排查连接错误、优化性能与设置安全选项，对 OAT 在线应用传输及后续升级迁移也有参考价值，适合需要补齐 Informix 客户端环境的 Windows 32 位项目。

1. 一句连接串连着三样东西：CSDK 4.10 装完能干什么

某天接手一台要连老库的应用服务器，配置里只有一行Host=10.0.0.21;Server=ifx_ol;Service=9088;Protocol=onsoctcp;Database=prd;UID=appuser;PWD=***。这句连接串能不能跑通，取决于三样东西有没有对齐：驱动、网络服务名、字符集环境。Informix Client SDK 4.10 For Windows 就是把这堆东西一次性装进机器的工具包——它不只是个 ODBC 驱动，还带 SetNet32、sqlhosts 解析、ESQL/C 预编译器、.NET Provider 和一整套环境变量机制。适合谁：要维护存量 Informix 系统的后端开发、做数据迁移的工程师、以及被要求「在老系统上加个接口」然后一头雾水的运维。这篇按装、配、连、编译、排错的顺序推进，每一步都落到能照着敲的程度。

2. 装之前先算三笔账：组件、位数与环境变量

很多人拿到安装包就直接双击下一步，装完发现驱动在 ODBC 管理器里看不见，或者 .NET 引用编译过了运行时报找不到提供程序。问题多半不在安装包，而在动手前没算清三笔账：装哪些组件、装哪个位数、装完要配哪些变量。

2.1 组件勾选清单：只留真正用得上的

CSDK 的安装向导会把所有组件默认勾上，看起来省事，实际给后面留了隐患：多装一个 Client SDK 的 ESQL/C 编译器，就要多配一套 MSVC 环境；多装一个 OLE DB Provider，就多一份位数冲突的可能。常见做法是按「这台机器上的程序用什么协议连库」来反推。

我一般只勾 ODBC Driver、.NET Provider 和命令行工具三样，ESQL/C 和 OLE DB 等确认真有程序要用再补装。补装不用卸载重来，安装程序支持修改组件，代价比一开始全勾上小得多。

有一点容易忽略：安装路径别带空格和中文。默认会落在C:\Program Files\IBM\Informix\Client-SDK这种带空格的目录下，多数场景没问题，但 ESQL/C 编译时有些老式 Makefile 不会给包含路径加引号，一编译就是找不到头文件。我习惯改成C:\ifx_csdk，路径短、无空格，后面所有脚本都好写。

2.2 32 位与 64 位：驱动、Provider 和进程必须同层

这是翻车率最高的一处。Windows 上 32 位和 64 位是两个独立的世界：64 位系统里跑着两套 ODBC 数据源管理器，一套在C:\Windows\System32\odbcad32.exe（64 位），另一套在C:\Windows\SysWOW64\odbcad32.exe（32 位）。在 64 位管理器里配好的 DSN，32 位程序一个都看不见，反过来也一样。

判断依据只有一个：你的宿主进程是多少位。Python 用python -c "import struct;print(struct.calcsize('P')*8)"看，返回 32 就装 32 位 CSDK，返回 64 就装 64 位。IIS 应用池有个「启用 32 位应用程序」开关，开了就必须配 32 位驱动，这一条坑过太多人。

.NET 侧同理。IBM.Data.Informix.dll分 32/64 位版本，托管程序集本身是 AnyCPU 还是 x86/x64 决定了它加载哪个。很多项目在开发机上跑得好好的，部署到服务器上抛BadImageFormatException，就是位数对不上，跟代码一点关系没有。

注意：一台机器上同时装 32 位和 64 位 CSDK 是允许的，但必须装到不同目录，且 PATH 里只能让其中一套优先。混着放同一目录，注册表里的驱动路径会被后装的覆盖，表现是「昨天还好好的今天连不上」。

2.3 INFORMIXDIR 与 PATH：装完不配等于没装

安装程序会自己写INFORMIXDIR和PATH，但它写的是系统级变量，而且只在安装那一刻写一次。后面如果换目录、补装组件、或者把 CSDK 从测试机复制到生产机，变量就得手工维护。

必配的四项：

• INFORMIXDIR：指向 CSDK 根目录，例如C:\ifx_csdk。所有工具靠它找etc\sqlhosts和bin。
• INFORMIXSERVER：默认连接的数据库服务器别名，必须和 sqlhosts 里的第一列对得上。
• PATH：追加%INFORMIXDIR%\bin，否则ilogin、dbaccess、esql全都提示不是内部或外部命令。
• INFORMIXSQLHOSTS：当 sqlhosts 不在默认位置或要指向多个文件时设置，写完整文件路径。

用 PowerShell 看一眼当前值，比在图形界面里翻环境变量快：

# 查看 CSDK 相关变量是否齐全 Get-ChildItem Env: | Where-Object { $_.Name -match 'INFORMIX|CLIENT_LOCALE|DB_LOCALE' } | Sort-Object Name | Format-Table -AutoSize # 确认 bin 目录真的在 PATH 里，以及工具能不能被找到 $env:PATH -split ';' | Where-Object { $_ -like '*ifx*' -or $_ -like '*Informix*' } Get-Command ilogin, dbaccess, esql -ErrorAction SilentlyContinue | Select-Object Name, Source

第一段列出所有 Informix 相关变量，第二段确认bin目录在不在 PATH、三个核心工具解析到哪个路径。如果Get-Command什么都不返回，说明 PATH 没生效——注意改完系统变量要重开终端，已经打开的 cmd/PowerShell 不会自动刷新。

这里有个血泪经验：机器上装了两套 CSDK 时，PATH 里靠前的那套决定esql和ilogin用哪个版本，但 ODBC 驱动是注册表里按名字解析的，两者可以不一致。表现是命令行连得上、应用连不上，或者反过来。排查时先Get-Command esql看路径，再查注册表里的驱动路径，两边对比。

3. 打通第一条连接：SetNet32、sqlhosts 与 ODBC 的落地顺序

环境和组件就位后，下一步是让机器知道「数据库服务器在哪、走什么协议、叫什么名字」。这三件事在 Informix 里由 sqlhosts 描述，而 SetNet32 是图形化的写入工具。理解两者的关系，比记住点哪个按钮重要得多。

3.1 SetNet32 写进注册表的那几个值

SetNet32（%INFORMIXDIR%\bin\setnet32.exe）表面上是个配置窗口，实际做的是往注册表写一条服务器定义。它管五个字段：

• Informix Server：服务器别名，要和应用连接串里的Server=一致，不是数据库名。
• HostName：数据库服务器的 IP 或可解析主机名。
• Protocolname：TCP 场景固定写onsoctcp。老系统里可能见到ontlitcp、olsoctcp、sesoctcp，这些是不同产品线或加密选项的变体，抄错一个就连不上。
• Service Name：端口号或 services 文件里定义的服务名。
• Options：一般留空，某些场景下写连接参数。

这些值最终落到HKEY_LOCAL_MACHINE\SOFTWARE\Informix\SetNet32（32 位工具在 64 位系统上会写进WOW6432Node分支）。用 PowerShell 可以直接核对，不用开图形界面：

# 检查 SetNet32 写入的服务器定义，两个分支都要看 $paths = @( 'HKLM:\SOFTWARE\Informix\SetNet32', 'HKLM:\SOFTWARE\WOW6432Node\Informix\SetNet32' ) foreach ($p in $paths) { if (Test-Path $p) { Write-Host "== $p" -ForegroundColor Cyan # 只取和连接相关的子键，避免刷屏 Get-ChildItem $p | Where-Object { $_.Name -match 'Server|Host|Service|Protocol' } | ForEach-Object { "{0} = {1}" -f $_.PSChildName, (Get-ItemProperty $_.PSPath).'(default)' } } }

这段脚本遍历两个注册表分支，只打印服务器、主机、服务、协议相关的项。参数说明：$paths里必须两个分支都查，因为你不知道自己刚才开的是 32 位还是 64 位版本的 SetNet32；Where-Object的过滤条件放宽到四个关键词，是因为不同 CSDK 小版本写入的子键命名略有差异。查到结果后重点看两项：HostName 是不是数据库服务器的真实地址，Service Name 能不能和 DBA 给的端口对上。

SetNet32 会同时维护一个「当前服务器」的概念，也就是设置INFORMIXSERVER。这一步千万别和图省事混过去——INFORMIXSERVER指向的别名必须在 sqlhosts 里存在，否则所有命令行工具启动时就报 -908。

3.2 sqlhosts 手写还是工具生成

sqlhosts 是个纯文本文件，每行一条服务器定义，格式是「别名 协议 主机名 服务名」。查找顺序是：INFORMIXSQLHOSTS环境变量指定的文件 →%INFORMIXDIR%\etc\sqlhosts.%INFORMIXSERVER%→%INFORMIXDIR%\etc\sqlhosts。理解这个顺序能省下大量「我明明改了却没生效」的时间。

# %INFORMIXDIR%\etc\sqlhosts # 别名 协议 主机名 服务名/端口 ifx_ol onsoctcp 10.0.0.21 9088 ifx_ol_bak onsoctcp 10.0.0.22 9088 ifx_rep onsoctcp 10.0.0.21 9099

四列之间用空白分隔，#开头是注释。第一列就是INFORMIXSERVER或连接串里Server=要写的值；第二列协议必须和服务器端sqlhosts一致，这是双向约定，只改客户端没用；第三列建议写 IP 而不是主机名，除非你确定 DNS 解析稳定；第四列写端口号最省事，写服务名则需要在C:\Windows\System32\drivers\etc\services里有对应条目。

手写和用 SetNet32 的差别在哪？SetNet32 写的是注册表，而 Informix 客户端在 Windows 上会同时参考注册表和 sqlhosts 文件，两者冲突时以 sqlhosts 为准（当INFORMIXSQLHOSTS显式指定时更是如此）。我的习惯是：单机调试用 SetNet32 图快，一旦要交付、要进版本管理、要在多台机器复现，一律手写 sqlhosts 文件并纳入配置管理。因为文本文件能 diff、能 code review、能随应用一起打包，注册表不能。

3.3 用 ilogin 先验通路，再上应用

配置完不要急着写代码。先用ilogin做一次纯连接测试，它只干一件事：连上去，然后退出。这一步能把「网络/服务名/认证」和「应用代码」两类问题彻底切开。

# 交互式登录：依次输入服务器别名、用户名、密码 ilogin # 也可以把参数写在命令行，适合脚本化自检 ilogin -d prd -u appuser -p '******' ifx_ol

参数说明：-d指定数据库名，不写则只连服务器不打开库；-u/-p是账号密码；最后一个位置参数是 sqlhosts 里的服务器别名。返回login succeeded说明链路通了，剩下的问题就都在应用侧。

接着验证 ODBC。注意要打开位数匹配的那个管理器：64 位程序用C:\Windows\System32\odbcad32.exe，32 位程序用C:\Windows\SysWOW64\odbcad32.exe。添加系统 DSN 时驱动名选IBM INFORMIX ODBC DRIVER，然后在 Server、Host、Service、Protocol、Database 几个框里填和 sqlhosts 一致的值。测试连接按钮背后走的就是驱动本身的握手逻辑，能过基本就稳了。

不配 DSN 也能连，用无 DSN 连接串更灵活，尤其适合容器和配置中心场景：

import pyodbc # 无 DSN 连接：所有信息都写在连接串里，便于配置外置 conn_str = ( "Driver={IBM INFORMIX ODBC DRIVER};" # 驱动名必须和管理器里注册的完全一致 "Host=10.0.0.21;" # 数据库服务器地址 "Server=ifx_ol;" # sqlhosts 里的别名，不是数据库名 "Service=9088;" # 端口，和 sqlhosts 第四列对应 "Protocol=onsoctcp;" # TCP 协议，抄错就连不上 "Database=prd;" # 要打开的库 "UID=appuser;PWD=******;" "CLIENT_LOCALE=zh_CN.GB18030;" # 客户端字符集，需与服务端匹配 "DB_LOCALE=zh_CN.GB18030;" # 数据库字符集 ) with pyodbc.connect(conn_str, timeout=10) as conn: cur = conn.cursor() cur.execute("SELECT FIRST 3 tabname FROM systables WHERE tabid > 99") for row in cur.fetchall(): print(row[0])

逻辑说明：连接串里Driver、Host、Server、Service、Protocol五项是最小必需集，少一项就是各种 -25596 或 -908。timeout=10很重要，默认超时可能长达几十秒，网络不通时会把启动流程拖死。CLIENT_LOCALE和DB_LOCALE成对出现，只写一个容易触发字符集转换告警甚至乱码。查询用systables只是为了验证链路，tabid > 99过滤掉系统表。

如果pyodbc.drivers()里根本看不到 Informix 驱动，先别怀疑连接串，回头查位数——这是最常见的原因，没有之一。

4. 从预编译到托管调用：ESQL/C 与 .NET Provider 的最小样例

链路通了，接下来才是开发侧的事。CSDK 提供两条典型路径：一条是给存量 C 程序用的 ESQL/C，一条是给现代托管应用用的 .NET Provider。两条路的配置重心完全不同，混在一起谈容易糊涂。

4.1 ESQL/C：一条 esql 命令背后的四步

ESQL/C 的核心是「嵌 SQL 的 C 文件」（.ec）不能直接编译，必须先由esql预编译器把EXEC SQL段落翻译成标准 C 调用，再交给 C 编译器。esql本身就是个包装器：它先做预编译，然后自动调用 MSVC 完成编译链接。

/* demo.ec —— 最小可跑的 ESQL/C 示例 */ #include <stdio.h> EXEC SQL include sqlca; /* 必须包含，错误信息在 sqlca 里 */ int main(void) { /* 连接串写法：数据库@服务器别名，用户名和口令分开给 */ EXEC SQL connect to 'prd@ifx_ol' user 'appuser' using '******'; if (sqlca.sqlcode != 0) { printf("connect failed: %d\n", sqlca.sqlcode); return 1; } EXEC SQL BEGIN DECLARE SECTION; char name[64]; EXEC SQL END DECLARE SECTION; /* 取一条数据，宿主变量用冒号前缀 */ EXEC SQL select tabname into :name from systables where tabid = 100; printf("tabname=%s sqlcode=%d\n", name, sqlca.sqlcode); EXEC SQL disconnect current; return 0; }

编译命令：

# 先确认 esql 在 PATH 里，且 INFORMIXDIR 正确 esql -o demoapp.exe demo.ec

逻辑说明：esql会做四件事——预处理.ec生成.c、带上%INFORMIXDIR%\incl\esql的头文件路径、链接%INFORMIXDIR%\lib下的运行库、调用cl.exe出可执行文件。参数-o指定输出名，不写会用默认名。要加额外编译选项用-cflag，加链接选项用-lflag，比如esql -o demoapp.exe -cflag "-MT" demo.ec让运行时静态链接 CRT。

几个必然踩到的点：sqlca不 include 编译能过但错误码永远是 0，排错时等于闭眼；宿主变量必须以冒号开头，忘了就是编译报错；connect to的字符串不能太长，别名和库名要严格对应 sqlhosts。最要命的是环境——esql依赖INFORMIXDIR找头文件和库，而这个变量如果在 IDE 里配置的构建任务中不存在，编译出来一堆找不到sqlca.h的错。

4.2 .NET Provider：引用、GAC 与连接串写法

.NET 侧就简单得多，前提是程序集能被正确加载。IBM.Data.Informix.dll随 CSDK 安装，位置在%INFORMIXDIR%\bin\netf40之类的目录（不同小版本路径略有差异）。项目里直接加引用即可，但要注意位数要与目标进程一致。

using System; using IBM.Data.Informix; // 需要先引用 IBM.Data.Informix.dll class Program { static void Main() { // 连接串字段与 ODBC 基本一致，少了 Driver 多了若干可选参数 string cs = "Host=10.0.0.21;Server=ifx_ol;Service=9088;" + "Protocol=onsoctcp;Database=prd;" + "UID=appuser;PWD=******;"; try { using (var conn = new IfxConnection(cs)) { conn.Open(); // 打开失败会抛 IfxException using (var cmd = conn.CreateCommand()) { cmd.CommandText = "SELECT COUNT(*) FROM systables"; int n = Convert.ToInt32(cmd.ExecuteScalar()); Console.WriteLine($"tables={n}"); } } } catch (IfxException ex) { // 错误码在 ex.Errors 里，逐个打出来比只看 Message 有用 foreach (IfxError e in ex.Errors) Console.WriteLine($"code={e.NativeError} msg={e.Message}"); } } }

逻辑说明：IfxConnection的构造不做任何网络动作，Open()才真正握手，所以连接失败一定发生在Open那一行。异常处理里遍历ex.Errors是关键——Message往往只有一句话，而NativeError里的负数码才是定位依据。连接串中Protocol和Service必须和 sqlhosts 一致，否则报 -908。

部署时还有一关：目标机器上必须有 Provider。两种做法，一是随应用把IBM.Data.Informix.dll一起拷过去，二是在服务器上装 CSDK 后把程序集注册进 GAC。前者灵活但要注意依赖链，后者稳妥但要求每台机器都装。托管应用还涉及IfxDataReader之类的高级类型，用DbProviderFactories注册的场景需要改machine.config，这属于另一个话题了。

4.3 字符集三件套：DB_LOCALE、CLIENT_LOCALE、SERVER_LOCALE

中文场景下字符集是玄学重灾区。三个变量的职责划分：DB_LOCALE声明数据库本身用什么编码，CLIENT_LOCALE声明客户端程序期望什么编码，SERVER_LOCALE是服务端默认值。客户端的转换发生在中间这两者之间，任何一个写错都会得到乱码或者 -79708 这类转换失败错误。

经验规则：

• 老库多为en_US.819（ISO-8859-1）或zh_CN.GB18030，先问 DBA 要服务端的DB_LOCALE实际值，别猜。
• 客户端如果处理中文，CLIENT_LOCALE设zh_CN.GB18030或zh_CN.GBK，与DB_LOCALE保持一致时最省心。
• 用 UTF-8 库时两者都设en_US.UTF-8或zh_CN.UTF-8，注意拼写里的点是大写还是小写都有讲究，抄官方文档格式最稳。
• 这三个变量在 Windows 上走环境变量，但也可以通过连接串里传，程序内部设置CLIENT_LOCALE对某些驱动不一定生效，环境变量更可靠。

改完环境变量必须重开进程。IIS 这种常驻进程要重启应用池，否则拿的还是旧值——这条坑过的人不少。

5. 排查手册：连接报错时先看这五条现场记录

错误码只是入口，真正的位置信息藏在环境里。finderr工具能查错误说明，但finderr -25596告诉你的只是「网络驱动无法建立连接」，至于为什么不能，得靠外部信息。下面是几条反复出现的现场，写法统一成「现象 → 原因 → 解决」。

5.1 五条踩坑记录

现象一：所有工具都报 -908，但 telnet 端口是通的。原因：INFORMIXSERVER的值在 sqlhosts 里找不到对应行，或者 sqlhosts 文件被加载的不是你改的那份。查找顺序里INFORMIXSQLHOSTS优先级最高，一旦被设过一个陈旧的路径，后面改默认文件都不会生效。 解决：先echo %INFORMIXSQLHOSTS%确认是否被设置，再用finderr -908确认语义，最后核对 sqlhosts 第一列与INFORMIXSERVER字符串是否逐字符相同（包括下划线和大小写，别小看这点）。多台机器同步配置时，我一般会写个自检脚本，把别名、协议、端口三项打印出来比对。

现象二：ODBC 管理器里看得到驱动，Python 连接报 "Data source name not found and no default driver specified"。原因：驱动看不到。最常见的不是没装，而是位数错配——32 位 Python 在 64 位驱动列表里找驱动，永远找不到。 解决：python -c "import struct;print(struct.calcsize('P')*8)"确认位数，装对应版本 CSDK，或换 64 位解释器。判断前先跑pyodbc.drivers()把列表打出来，比猜快。这条我踩过不止一次，现在养成习惯：任何新环境第一件事就是打驱动列表和解释器位数。

现象三：应用启动正常，一查询就报 -23101，或者 .NET 侧抛BadImageFormatException。原因：托管程序集位数和宿主进程不匹配。AnyCPU 的程序在 64 位系统上默认跑 64 位，引用的却是 32 位IBM.Data.Informix.dll。 解决：把项目目标平台显式设为 x86 或 x64，和 CSDK 位数对齐；或者给同一台机器装两套 CSDK，用不同发布配置区分。IIS 场景还要检查应用池的「启用 32 位应用程序」开关，这个开关和项目平台设置会打架，以应用池为准。

现象四：少量中文出现问号或方块，英文和数字正常。原因：CLIENT_LOCALE和DB_LOCALE不一致，或者服务端 locale 与客户端 locale 之间的转换路径不存在。表现往往是「大部分能显示，个别生僻字挂掉」，因为转换是逐字符做的。 解决：向 DBA 要到服务端实际 locale，客户端两个变量与之对齐；用SELECT FIRST 1 COLLATION()之类的方式验证服务端返回值。改完重启应用进程，常驻服务尤其要重启，环境变量不会热加载。数据库连接池里已经建立的连接同样持有旧 locale，得等池清空。

现象五：ESQL/C 编译报找不到sqlca.h，或者链接期报未解析的外部符号。原因：esql没找到INFORMIXDIR，或者 PATH 里优先的是另一套 CSDK。IDE 里的构建任务和命令行终端的环境变量不是一回事，这是最容易漏的一处。 解决：在构建脚本里显式设置INFORMIXDIR再调esql，不要依赖系统变量；用esql -V之类的方式确认实际调用的是哪套；链接期缺符号多半是库路径不对，检查%INFORMIXDIR%\lib下有没有对应位数的库文件。我把这套检查固化进了构建脚本开头，编译失败时先看这几行输出。

提示：排错顺序建议固定成「环境变量 → sqlhosts → 位数 → 字符集 → 应用代码」。从下往上查，很容易在代码里绕半天，最后发现是 PATH 少了一段。

6. 把 CSDK 固化进构建流程：一次配好，后面少返工

装一次配一次的做法只适合单机调试。真正省时间的做法是把环境固化成脚本，让每台机器、每次构建都跑同一套自检逻辑。

6.1 用脚本固化环境与连通性自检

我一般会在项目仓库里放一个setup-ifx.ps1，职责就三件：校验环境变量、校验 sqlhosts 内容、跑一次连接探活。构建流水线的第一步就跑它，失败早于编译失败，定位成本低一个量级。

# setup-ifx.ps1 —— 构建前自检，任一项失败立即退出 $ErrorActionPreference = 'Stop' # 1) 环境变量齐全性 foreach ($v in 'INFORMIXDIR','INFORMIXSERVER') { if (-not (Test-Path "Env:$v")) { throw "缺少环境变量 $v" } } Write-Host "INFORMIXDIR=$env:INFORMIXDIR SERVER=$env:INFORMIXSERVER" # 2) sqlhosts 里必须存在当前服务器别名 $hostsFile = if ($env:INFORMIXSQLHOSTS) { $env:INFORMIXSQLHOSTS } else { Join-Path $env:INFORMIXDIR 'etc\sqlhosts' } $line = Get-Content $hostsFile | Where-Object { $_ -and $_ -notmatch '^\s*#' -and $_.Split()[0] -eq $env:INFORMIXSERVER } if (-not $line) { throw "sqlhosts 中找不到 $env:INFORMIXSERVER" } Write-Host "sqlhosts: $line" # 3) 探活：用 ilogin 连一次，非零退出码视为失败 & (Join-Path $env:INFORMIXDIR 'bin\ilogin.exe') -d $env:IFX_DB ifx_ol if ($LASTEXITCODE -ne 0) { throw "ilogin 连接失败，退出码 $LASTEXITCODE" }

逻辑说明：三段检查分别对应最容易出问题的三处。第一段保证变量没丢，Test-Path "Env:xxx"是 PowerShell 里判断环境变量的标准写法。第二段按 sqlhosts 的实际查找规则选文件，跳过注释行和空行后比对第一列，这一步能挡住「别名写错一个字母」这种低级但高频的问题。第三段调ilogin做真实握手，$LASTEXITCODE非零即失败。参数$env:IFX_DB是自定义的库名变量，从 CI 的密钥管理里注入，不写死在脚本里。

6.2 多版本共存时的取舍

一个绕不开的场景：同一台机器要连两套不同版本的数据库，需要两套 CSDK。可行，但代价要认。

我的选择是第二种优先、第一种兜底。高版本客户端连低版本服务端在大多数场景兼容，先用探活脚本验证，通了就别折腾双版本。真要共存，务必给每套写独立的启动脚本，把INFORMIXDIR、PATH、INFORMIXSQLHOSTS三个一起设，不要只改一个。

有一套习惯从那以后我一直保持着：任何新机器上第一次接触 Informix，先跑一遍「变量、sqlhosts、ilogin、驱动列表」四件事，四样都对上再动代码。这四步花不到五分钟，能省掉后面几个小时在一堆负数码里翻找的时间。希望帮到你。

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