『壹』 求助，informix客戶端連接資料庫，報密碼錯誤
1，在ASPX頁面上拖兩個TextBox，一個用於輸入用戶名，一個用於輸入密碼。還有一個Button,給這個Button的Click事件添加判斷用戶名，密碼是否正確的功能，具體見2
2，從頁面獲取到用戶名和密碼，在資料庫的表中，查找用戶名為你輸入用戶名的記錄，如果沒有查到，提示「用戶名不存在」。如果查找到記錄，取出記錄對應的用戶名和密碼信息，比較查尋出來的密碼和輸入的密碼是否一致，不一致，提示「密碼錯誤」。如果密碼也正確，你可以顯示登錄成功，或者是跳轉到其他一些有用的頁面。
『貳』 如何正確設置 Informix GLS 及 CSDK 語言環境
GLS 基本概念
字元（Character）是各種文字和符號的總稱，包括各國家文字、標點符號、圖形符號、數字等。字元集（Character set）是多個字元的集合，字元集種類較多，每個字元集包含的字元個數不同，常見字元集名稱：ASCII字元集、GB2312字元集（簡體中文）、BIG5字元集（繁體中文）、 GB18030字元集（亞洲字元集合）、Unicode( 常用 UTF-8) 字元集等。
Informix GLS 語言環境對常用的字元集進行了命名及內部編碼（採用 16 進制編碼）管理。通過伺服器端的文件：$InformixDIR/gls/cm3/registry 查看 GLS 字元名稱、編碼對照表。示例如下：
字元集名稱 編碼 十六進制編碼
8859-1 819 # 0x0333
gb 57357 # 0xe00d
GB2312-80 57357 # 0xe00d
utf8 57372 # 0xe01c
big5 57352 # 0xe008
GB18030-2000 5488 # 0x1570
GLS 環境中不同字元集名稱可能對應同一個字元集編碼，但一個字元集只能有一個編碼，也就是說字元集編碼才是唯一的。
GLS
環境中按照語言和地區把所支持的字元集分成不同的目錄。$InformixDIR/gls/lc11/ 語言 _ 地區
/，如中文大陸地區的目錄為：$InformixDIR/gls/lc11/zh_cn/，該目錄下有如下兩個文件：1570.lco e00d.lco
，說明我們在設置字元集時，我們可以使用 zh_cn.GB18030-2000 zh_cn.gb zh_cn.GB2312-80
三個不同的名稱。這里（zh_cn.gb 與 zh_cn.GB2312-80 對應相同的字元集）。
GLS
環境中不同的字元集可以正確的進行轉換，查看那些字元集可以正確轉換的方法，查看目錄 $InformixDIR/gls/cv9
目錄下的是否存在指定字元集互相轉換的文件。如該目錄下有文件 e01ce00d.cvo 和 e00de01c.cvo 兩個文件，表示 GLS
通過這兩個轉換文件支持 UTF-8 與 GB 之間的字元轉換。
Informix 通過 DB_LOCALE 和 CLIENT_LOCALE 來設置資料庫的語言本地化支持設置。DB_LOCALE 和 CLIENT_LOCALE 的值由四部分組成 ( 第 4 部分為可選 )，字元集不區分大小寫。
1 2 3 4
< 語言 >_< 國家和地區 >.< 字元集名 / 字元集編碼 >[@modifier]
舉例說明 :
CLIENT_LOCALE=en_us.8859-1
CLIENT_LOCALE=en_us.819
# 以上兩個為同一字元集：819 為 8859-1 的編碼
DB_LOCALE=zh_cn.gb
回頁首
GLS 字元集工作原理
Informix 資料庫伺服器端、客戶端字元集的工作原理示意圖見圖 1。
圖 1. IDS GLS 字元集處理過程示意圖
DB_LOCALE 環境變數用途
在客戶機應用程序和資料庫伺服器交換字元數據時，如果 DB_LOCALE 環境變數（在客戶機計算機上）的值與 CLIENT_LOCALE 的值不同，客戶機應用程序將執行代碼集轉換。 代碼集轉換防止這兩種代碼集不同時發生數據破壞。
在客戶機應用程序請求連接時，它將包括 DB_LOCALE（如果已設置）的信息發送至資料庫伺服器。
在確定如何設置伺服器處理語言環境的資料庫信息時，資料庫伺服器使用 DB_LOCALE。
在客戶機應用程序嘗試打開資料庫時，資料庫伺服器將客戶機應用程序傳遞的 DB_LOCALE 環境變數的值與資料庫中存儲的資料庫語言環境進行比較。
當資料庫伺服器存取與語言環境相關的數據類型的列時，資料庫伺服器使用 DB_LOCALE 指定的語言環境。
當資料庫伺服器創建新資料庫時，它將檢查資料庫語言環境（DB_LOCALE），以確定如何在資料庫的系統目錄中存儲字元信息。此信息包括諸如如何處理正則表達式、比較字元串以及確保代碼集的正確使用的操作。
CLIENT_LOCALE 環境變數用途
在客戶機應用程序和資料庫伺服器交換字元數據時，如果 CLIENT_LOCALE 環境變數的代碼集與 DB_LOCALE（在客戶機計算機上）的代碼集不同，客戶機應用程序將執行代碼集轉換。代碼集轉換防止這兩種代碼集不同時發生數據破壞。
在客戶機應用程序請求連接時，它將包括 CLIENT_LOCALE 的信息發送至資料庫伺服器。
在確定如何設置伺服器處理語言環境的客戶機應用程序信息時，資料庫伺服器將使用 CLIENT_LOCALE。
在 Informix Esql/C 的預處理器處理源文件時，它接受以 CLIENT_LOCALE 的代碼集編寫的 C 源代碼。 在
Informix ESQL/C 客戶機應用程序執行時，將檢查 CLIENT_LOCALE
以獲得客戶機語言環境的名稱，該語言環境將對操作系統文件名、文本文件的內容以及日期、時間和數字數據的格式產生影響。
在資料庫實用程序創建文件時，文件名和文件內容位於 CLIENT_LOCALE 指定的代碼集中。在查找特定於產品的消息文件時，客戶機應用程序將檢查與客戶機語言環境關聯的消息目錄。
四個語言環境的含義
客戶機語言環境— Client locale
客戶機語言環境指定客戶機應用程序用於執行讀和寫（I/O）操作的語言、地域和代碼集。在客戶機應用程序中，I/O
操作包括讀取鍵盤輸入或要發送至資料庫的數據文件，以及將資料庫伺服器從資料庫中檢索的數據寫入屏幕、文件或列印機。 通過 CLIENT_LOCALE
來設置客戶機語言環境。
資料庫語言環境— Database locale
通過 DB_LOCALE 環境變數設置的資料庫語言環境指定資料庫伺服器用於正確解釋特定資料庫中語言環境相關的數據類型（NCHAR 和
NVARCHAR）所需的語言、地域和代碼集。DB_LOCALE
中指定的代碼集確定哪些字元在任何字元列中都是有效的，並且確定資料庫對象（如資料庫、表、列和視圖）的名稱。資料庫伺服器使用 DB_LOCALE
環境變數指定的資料庫代碼集將數據傳入和傳出資料庫。
伺服器語言環境— Server locale
資料庫伺服器使用 SERVER_LOCALE 環境變數指定的伺服器代碼集寫文件（如調試和警告文件）。但是，資料庫伺服器不使用伺服器語言環境來寫入採用 Informix 專用格式的文件（資料庫和表文件）。
伺服器處理語言環境— Server processing locale
資料庫伺服器使用資料庫語言環境的代碼集作為伺服器處理語言環境的代碼集 , 使用伺服器處理語言環境來寫入採用 Informix
專用格式的文件（資料庫和表文件）。也就是說資料庫伺服器使用資料庫語言環境（DB_LOCALE）來寫入採用 Informix
專用格式的文件（資料庫和表文件）。
建立資料庫連接過程
在客戶機應用程序請求與資料庫的連接時，資料庫伺服器使用 GLS 語言環境執行以下步驟。
客戶機應用程序發送語言環境信息到資料庫伺服器。
CLIENT_LOCALE( 未設置將採用默認 en_us.819)；
DB_LOCALE( 未設置則不發送 )。
驗證是否能夠在客戶機應用程序及其請求的資料庫之間建立連接。
對比如下兩個語言環境：
匹配，則建立連接。
不匹配，提示無法連接到資料庫。或者可以繼續進行這樣的連接，但是資料庫伺服器可能會不正確地解釋它從客戶機接收到的數據，那麼只能靠自己來理解交換中數據的格式。
由客戶機應用程序發送的 DB_LOCALE 指定的語言環境；
存儲在請求資料庫的系統目錄中的資料庫語言環境。
確定伺服器處理語言環境，按如下順序確定伺服器處理語言環境：
使用客戶機定義的 DB_LOCALE；
資料庫語言環境中的環境變數 DB_LOCALE。
執行代碼集轉換
在客戶機 / 伺服器環境中，如果客戶機或伺服器計算機使用不同的代碼集來表示相同的字元，那麼需要將字元數據從一種代碼集轉換為另一種代碼集。如果不進行代碼集轉換，那麼一台計算機無法正確地處理或顯示源自另一台計算機的字元數據（在這兩台計算機使用不同的代碼集時）。
何時執行代碼集轉換
只有在兩個代碼集（客戶機和伺服器處理語言環境，或伺服器處理語言環境和伺服器）不同時，應用程序才必須使用代碼集轉換。以下情況是代碼集不同的可能原因：
不同的操作系統可能以不同的方式對同一字元進行編碼。
如果客戶機語言環境和資料庫語言環境指定不同的代碼集，客戶機應用程序將執行代碼集轉換以便伺服器計算機不會裝入此類型的處理。
如果伺服器語言環境和伺服器處理語言環境指定不同的代碼集，資料庫伺服器將在寫入和讀取操作系統文件（如日誌文件）時執行代碼集轉換。該轉化不涉及到資料庫數據的問題。
在圖 1 中，黑點表示在客戶機 / 伺服器環境中可能發生代碼集轉換的兩個時刻。
客戶機應用程序代碼集轉換
當以下兩個條件都為真時，客戶機應用程序自動在客戶機和資料庫代碼集之間執行代碼集轉換：
客戶機和資料庫語言環境的代碼集不匹配。
客戶機和資料庫代碼集之間的轉換存在有效的目標代碼集轉換。
客戶機應用程序開始執行時，它會比較客戶機和資料庫語言環境的名
稱，以確定是否執行代碼集轉換。如果設置了 CLIENT_LOCALE 和 DB_LOCALE
環境變數，那麼客戶機應用程序使用這些語言環境名稱來分別確定客戶機和資料庫的代碼集。如果未設置 CLIENT_LOCALE（且未設置
DBNLS），那麼客戶機應用程序假定客戶機語言環境為預設語言環境。如果未設置 DB_LOCALE（且未設置
DBNLS），那麼客戶機應用程序假定資料庫語言環境與客戶機語言環境（CLIENT_LOCALE 設置的值）相同。
如果客戶機和資料庫代碼集相同，那麼無需進行代碼集轉換。但是，如果代碼集不匹配，客戶機應用程序必須確定這兩個代碼集是否可轉換。如果客戶機可以找到關聯的代碼集轉換文件，那麼兩個代碼集是可轉換的。這些代碼集轉換文件必須存在於客戶機計算機上。
舉例說明：
客戶機應用程序：CLIENT_LOCALE=en_us.1252 DB_LOCALE=en_us.8859-1
客戶機應用程序確定它必須在 Windows 代碼頁 1252（客戶機語言環境中）和
ISO8859-1 代碼集（資料庫語言環境中）之間執行代碼集轉換。
若鏈接具有 GB(zh_cn.gb) 語言環境的資料庫，那麼資料庫將設置 SQLWARN 警告，原因是語言、地區和代碼
集不同。客戶機應用程序將不正確地執行代碼集轉換。
它將繼續在 Windows 代碼頁 1252 和 ISO8859-1 之間，而不是在 Windows 代碼頁 1252 和 zh_cn.gb 之間進行
轉換。這種情況可能會導致數據破壞。應用程序將不會繼續此鏈接。
回頁首
設置字元集
Informix 通過 DB_LOCALE 和 CLIENT_LOCALE 來設置資料庫的語言本地化支持設置。
資料庫服務端
在創建資料庫時（為了統一系統資料庫與應用資料庫的字元集，在創建資料庫實例時），請按如下步驟設置資料庫的 DB_LOCALE 值。
1. 設置環境變數 DB_LOCALE
set DB_LOCALE=zh_cn.gb
2. 創建資料庫 create database dbname
3. 驗證當前資料庫字元集
SELECT dbs_collate FROM sysmaster:sysdbslocale
WHERE dbs_dbsname = 『 dbname 』
客戶端
當我們使用 ODBC,JDBC 連接資料庫時，我們需要在連接信息中正確設置語言環境變數：DB_LOCALE 和 CLIENT_LOCALE。
設置語言環境變數
DB_LOCALE=zh_cn.gb
CLIENT_LOCALE=zh_cn.gb
ODBC：
下圖為 WINDOWS 環境下 ODBC 語言環境設置示意圖。
圖 2. 在 ODBC 中設置語言環境
UNIX 環境下需要在 odbc.ini 文件中定義：
在 odbc.ini 文件中定義如下兩項資料庫語言環境變數
DB_LOCALE=zh_cn.gb
CLIENT_LOCALE=zh_cn.gb
JDBC：
在使用 JDBC 連接資料庫時，我們需要在連接資料庫的 URL 中設置資料庫語言環境變數：DB_LOCALE 和 CLIENT_LOCALE。示例如下：
String url = "jdbc:Informix-sqli://10.127.1.11:8001/testdb:
InformixSERVER=servername;user=user;password=password;
DB_LOCALE=zh_CN.gb;CLIENT_LOCALE=zh_CN.gb";
回頁首
常見字元集設置問題
在 Informix 資料庫字元集設置與使用過程，我們常會遇到一些字元集相關錯誤，知道了錯誤產生的原因，就可以很容易解決問題。這里我們總結了幾種常見的字元集設置相關問題。
Error -23101 Unable to load locale categories
當設置的 DB_LOCALE 和 CLIENT_LOCALE 的字元集對應的以下文件不存在時，出現該錯誤。
- $InformixDIR/gls/lc11/DB_LOCALE's( 語言 _ 地區 )/(db 的 16 進制編碼 ).lco
- $InformixDIR/gls/lc11/CLIENT_LOCALE's( 語言 _ 地區 )/( db 的 16 進制編碼 ).lco
- $InformixDIR/gls/lc11/CLIENT_LOCALE's( 語言 _ 地區 )/( client 的 16 進制編碼 ).lco
舉例說明：
DB_LOCALE = en_us.utf8 #（對應的 16 進制編碼為：e01c）
CLIENT_LOCALE = zh_cn.gb18030-2000 #（對應的 16 進制編碼為：1570）
以下 3 個文件必須存在，缺任意文件將報 Error -23101。
- $InformixDIR/gls/lc11/en_us/e01c.lco
- $InformixDIR/gls/lc11/zh_cn/e01c.lco
- $InformixDIR/gls/lc11/zh_cn/1570.lco
Error -23104 Error opening required code-set conversion object file
當設置的 DB_LOCALE 和 CLIENT_LOCALE 的字元集對應的以下轉換文件不存在時，會出現該錯誤。當然只有當 DB_LOCALE 和 CLIENT_LOCALE 的字元集不一致時才會需要轉換，如果一致則不會出現 -23104 錯誤。
- $InformixDIR/gls/cv9/ccccdddd.cvo
- $InformixDIR/gls/cv9/ddddcccc.cvo
其中：cccc 為 CLIENT_LOCALE 字元集編碼對應的 16 進制值
dddd 為 DB_LOCALE 字元集編碼對應的 16 進制值
舉例說明
DB_LOCALE = en_us.utf8 #（對應的 16 進制編碼為：e01c）
CLIENT_LOCALE = zh_cn.gb18030-2000 #（對應的 16 進制編碼為：1570）
以下 2 個文件必須存在，缺任意文件將報 Error -23104。
- $INFOMRIXDIR/gls/cv9/e01c1570.cvo
- $INFOMRIXDIR/gls/cv9/1570e01c.cvo
Error -23197 Database locale information mismatch
當出現如下情況時，出現 -23197 錯誤。
定義的 DB_LOCALE 值與資料庫的使用的值（資料庫創建時使用的 DB_LOCALE 值）不一致；
通過 SET COLLATION 語句定義 DB_LOCALE 值與資料庫的使用值不一致 ;
舉例說明：
資料庫的 LOCALE= en_us.8859-1
可以通過如下 SQL 讀取當前資料庫的 LOCALE 值
SELECT dbs_collate FROM sysmaster:sysdbslocale WHERE dbs_dbsname = 『 dbname 』
客戶端 DB_LOCALE 設置如下（注意：如果沒有設置 DB_LOCALE，將使用在伺服器計算機上設置
的 DB_LOCALE），則會出現 -23197 錯誤
DB_LOCALE = zh_cn.gb
Error -201，-202 資料庫提示語法錯誤
Error -201，-202 資料庫提示語法錯誤，不支持中文對象名，如中文表名、欄位別名、視圖名。該類錯誤提示原因是當前資料庫的 DB_LOCALE 設置問題。
如果資料庫的 DB_LOCALE 設置為 zh_cn.GB18030-2000，則資料庫就可以支持中文對象名。
舉例說明：
DB_LOCALE = zh_cn.GB18030-2000 的資料庫，可以支持如下中文對象名，否則將提示語法錯誤。
Select c1 第一列 from test_cn;
Create table 中文表名 (c1 integer, 中文列名 integer);
drop table 中文表名 ;
若類似 SQL 不能運行，請核查資料庫的 DB_LOCALE 值。
SELECT dbs_collate FROM sysmaster:sysdbslocale WHERE dbs_dbsname = 『 dbname 』
亂碼問題
Informix
字元出現亂碼問題，或者不能正確顯示中文字元。問題的原因是客戶端 CLIENT_LOCALE 設置的值與 DB_LOCALE
值不一致，而且兩者對應的字元集之間不能正確進行轉換。需要重新設置 CLIENT_LOCALE 與 DB_LOCALE
的值，確保兩者一致或者可以正確相互轉換。
時間格式問題
Informix 資料庫的時間格式由資料庫伺服器端環境變數 GL_DATE GL_DATETIME 控制，默認的字元集下默認的時間格式為：
GL_DATE="%m/%d/%iy"
DATETIME="%iY-%m-%d %H:%M:%S"
但是，當我們設置了 DB_LOCALE 為
zh_cn.gb 的情形下，而沒有設置 GL_DATE,DATETIME，則時間格式會採用 CLIENT_LOCALE 的值，在
zh_cn.gb 情況下，會出現：「2009 年 10 月 2
日」的日期格式，如果我們之前系統採用默認的時間格式的情況下，就會出現時間格式不匹配的錯誤。如果我們仍然需要採用默認的時間格式，我們需要在資料庫服
務端修改時間格式環境變數即可：
GL_DATE="%m/%d/%iy"
DATETIME="%iY-%m-%d %H:%M:%S"
回頁首
GLS 對 CSDK 版本要求
CSDK2.8 及以上版本中（目前最新版本為 CSDK3.5），為了正確支持語言文字的處理，Informix GLS 語言環境下要求正確設置資料庫伺服器語言環境及客戶端語言環境。在中文語言環境下，我們應該按如下要求設置伺服器端和客戶端語言環境。
資料庫服務端：
在創建資料庫時（為了統一系統資料庫與應用資料庫的字元集，在創建資料庫實例時），請按如下步驟設置資料庫的 DB_LOCALE 值。
1. 設置環境變數 DB_LOCALE
set DB_LOCALE=zh_cn.GB18030-2000
2. 創建資料庫 create database dbname
3. 驗證當前資料庫字元集
SELECT dbs_collate FROM sysmaster:sysdbslocale
WHERE dbs_dbsname = 『 dbname 』
客戶端：
當我們使用 ODBC,JDBC 連接資料庫時，我們需要在連接信息中正確設置語言環境變數：DB_LOCALE 和 CLIENT_LOCALE。
設置語言環境變數
DB_LOCALE=zh_cn.GB18030-2000
CLIENT_LOCALE=zh_cn.GB18030-2000
CSDK2.7 版本，IDS 默認情況下使用
Garbage In, Garbage Out 模式處理中文字元，若資料庫伺服器上的 DB_LOCALE 採用默認的 en_us.8859-1
字元集，能夠正常支持中文字元。但是升級到 CSDK2.8 及以上版本時，不再支持 Garbage In, Garbage Out
模式，將出現亂碼問題。該情況下，建議更改資料庫的字元集（設置
DB_LOCALE=zh_cn.GB18030-2000，重新創建資料庫），然後按本文中描述的方法進行 DB_LOCALE 與
CLIENT_LOCALE 的設置方法進行處理。若在實際環境下重建資料庫成本太高，可以考慮如下步驟進行解決 ODBC 支持中文的問題。
資料庫伺服器端：
1. 設置環境變數： IFMX_UNDOC_B168163=1
2. 將 en_us.8859-1 字元集文件拷貝到 zh_cn 目錄下
cd $INFORMIXDIR/gls/lc11
cp ./en_us/0333.lco ./zh_cn
3. 重新啟動 IDS
客戶端：
設置語言環境：
l DB_LOCALE=zh_cn.GB18030-2000
l CLIENT_LOCALE=zh_cn.GB18030-2000
對於 JDBC 我們可以通過 NEWCODESET 來解決該問題：
URLString = "jdbc:Informix-sqli://9.125.66.130:6346/dbname:InformixSERVER=servername;
NEWCODESET=GB18030-2000,8859-1,819;
CLIENT_LOCALE=en_US.8859-1;DB_LOCALE=en_US.8859-1;"
『叄』 .net vs怎麼連接Informix資料庫
在使用 ADO.NET 驅動程序之前，應該確保該驅動程序已安裝並能正確運行。該驅動程序的當前版本可以使用 Informix Client Software Developer's Kit (SDK) 2.90 來安裝。與以前的 2.81 版本不同，此 SDK 版本包括默認的 ADO.NET 驅動程序。SDK 的安裝程序也會警告您有關事項。它並不真正在您的計算機上查找 .NET 框架的安裝，只是警告您必須在安裝 SDK 之前安裝好 .NET 框架。如果您已經安裝了 2.81 SDK，那麼最好先卸載它。這兩個版本無法共存。還要認識到的一點是，在將 2.90 ADO.NET 驅動程序添加到 Visual Studio Projects 中時，它會不正確地報告它自己是版本 2.81。
2.9 版本是在 2.81 版本之上的一次重要升級。它包括一個新的 IfxDataAdapter 向導、IPv6 支持和一些用於 Informix 數據類型（IfxDateTime、IfxDecimal、IfxBlob 和 IfxClob）的新類。該文檔更為完善，內容總量是以前的兩倍。
要點：IBM Informix ADO.NET 驅動程序並不僅僅包含在安裝目錄下的 /bin 目錄下的 IBM.Data.Informix.dll 文件中。顯然，它使用了由 SDK 安裝的其他客戶端代碼。這意味著您必須在所有將使用 ADO.NET 驅動程序的機器上安裝 Informix Client SDK。您不能只在您的發行版中包括 IBM.Data.Informix.dll。這對一些應用程序而言可能是一個嚴重的限制。您還需要仔細檢查 SDK 安裝程序 (SetNet32)，以定義 Informix 數據源。
在將 ADO.NET 驅動程序用於連接之前，還必須運行一個叫做 cdotnet.sql 的存儲過程。這個存儲過程位於 SDK 安裝的 /etc 目錄中。這類似於設置 OLEDB 驅動程序的過程，盡管這個過程更短一些。這個過程記錄在 User's Guide 中。（請參閱下面的參考資料部分。）
在完成安裝之後，檢查一下驅動程序，確保建立了連接。要在 Visual Studio 項目中使用 ADO.NET 驅動程序，則必須確保已將一個引用添加到客戶端 SDK 安裝的 /bin 目錄中找到的 IBM.Data.Informix.dll 中。正確的using語句是：using IBM.Data.Informix。以下是一個演示如何獲得到資料庫的連接的簡單方法：
清單1.到Informix資料庫的連接
publicvoidMakeConnection(){stringConnectionString="Host="+HOST+";"+"Service="+SERVICENUM+";"+"Server="+SERVER+";"+"Database="+DATABASE+";"+"Userid="+USER+";"+"Password="+PASSWORD+";";//,DB_LOCALEetc//FulllistinClientSDK's.NetProviderReferenceGuidep3:13IfxConnectionconn=newIfxConnection();conn.ConnectionString=ConnectionString;try{conn.Open();Console.WriteLine("Madeconnection!");Console.ReadLine();}catch(IfxExceptionex){Console.WriteLine("Problemwithconnectionattempt:"+ex.Message);}}
示例代碼中包括一個用於此功能的BasicConnection類。如您所見，ConnectionString只是一個用於連接的分號分隔的參數列表。Open()方法打開了到資料庫的連接，如果連接失敗，則拋出一個IfxException。IfxException.Message屬性通常提供關於失敗原因的合理數量的詳細信息
基本命令
一旦建立了連接，就可以開始對資料庫執行命令。要做到這一點，需要使用IfxCommand對象。IfxCommand的構造函數接收一個字元串（SQL 命令文本）和一個IfxConnection作為參數。IfxCommand對象有一系列的Execute方法，以便對資料庫執行命令。要清除連接，可以使用IfxConnection.Close()方法。以下是執行某個不返回結果集的簡單命令的例子。該命令可能是 insert、update 或 delete。
清單2.執行insert、update或delete命令
IfxCommandcmd;cmd=newIfxCommand("insertintotestvalues(1,2,'ABC')",conn);cmd.CommandTimeout=200;//{introws=cmd.ExecuteNonQuery();}catch(IfxExceptionex){Console.WriteLine("Error"+ex.Message);}
ExecuteNonQuery以整數形式返回受命令影響的行數。您還可以構建參數化語句和查詢，後面部分將對它們進行研究。注意IfxCommand的CommandTimeout屬性。默認超時時間是 30 秒，盡管在文檔中沒有對此進行說明。除非更改此屬性，否則運行 30 秒後，命令就會超時，並且將拋出一個異常。
下一個例子是執行一條 select 語句，並處理由資料庫伺服器返回的結果集。對於快速的、只向前通過結果的游標，可以使用由ExecuteReader方法返回的IfxDataReader。不過，每個IfxConnection只可以有一個打開的IfxDataReader。（這是一條 ADO.NET 限制，不是 Informix ADO.NET 驅動程序的特定限制。）
清單3.迭代通過IfxDataReader
IfxCommandcmd=newIfxCommand("select*fromtest",bconn.conn);try{IfxDataReaderdr=cmd.ExecuteReader();while(dr.Read()){inta=dr.GetInt32(0);intb=Convert.ToInt32(dr["b"]);stringc=(String)dr[2];}dr.Close();}catch(IfxExceptionex){Console.WriteLine("Error"+ex.Message);}
每一列都被作為一般的 Object 類型進行檢索。正如代碼所演示的，存在一些將列 Objects 轉換為正確數據類型的方法。您可以使用IfxDataReader的GetXxx方法。對於每種數據類型，幾乎都有相應的方法。GetXxx方法將列數目作為一個參數。可以使用IfxDataReader的索引，通過列的名稱來訪問列。如果可能的話，.NET 框架的Convert函數可以將這些 Objects 轉換為正確的類型。最後，可以根據列編號為這些列建立索引，並直接強制轉換結果（對於某些類型）。
下一個例子將展示如何調用需要一個參數值的存儲過程。
清單4.執行帶有一個參數的存儲過程
IfxCommandcmd=newIfxCommand("test_proc",conn);cmd.CommandType=CommandType.StoredProcere;//fromSystem.Datacmd.Parameters.Add("in_parameter",2);//manywaystocreatethesetry{cmd.ExecuteScalar();}catch(IfxExceptionifxe){Console.WriteLine("Error"+ifxe.Message);}
對於此IfxCommand，必須將CommandType設置為來自System.Data中的CommandType枚舉的StoredProcere值。為了創建參數，可以使用IfxCommand的Parameters.Add方法。IfxCommands.Parameters是一個集合，因此您可以添加您所需數量的參數。您可以使用任意IfxParameter()構造函數來創建參數，或者可以像上面這樣簡化參數的創建。不過要注意的是，每個IfxParameter都與一個特定的IfxCommand相關。您不能先創建IfxParameters，然後在多個IfxCommand對象中使用它們。ExecuteScalar()方法現在只返回 1。這一示例沒有從存儲過程返回任何東西。
要構建一個不執行存儲過程的參數化 SQL 語句，需要將問號作為佔位符插入CommandText中。例如：
清單5.參數化查詢
IfxCommandinsCmd=newIfxCommand("insertintoclientstest"+"(clientcode,clientacctname,primarycontact,primaddrcode,"+"initialamt,createdate)values(0,?,?,?,?,TODAY)",conn);
按照IfxParameter對象在命令文本中的順序，將這些對象添加到IfxCommand的Parameters集合中。在下面的擴展示例中的最終強類型化DataSets中，將進一步演示此技術。
強類型數據集
ADO.NET 包括一個叫做DataSet的專用資料庫對象。它是一個內存資料庫。DataSet由一個或多個（由一些DataRow對象的）DataTable對象組成。DataTable可以通過主鍵和外鍵相關聯。可以對數據設置一些約束。DataSet也與實際的數據存儲斷開連接，可以通過一個或多個DataAdapter（每個DataTable一個）來填充它，然後在內存中保存這些數據和所有更改。稍後，DataAdapter可以將這些更改提交回數據存儲。
基本的DataSet不是強類型的。它不知道資料庫的實際行和列是什麼。因此編譯器沒有檢查這些列名稱。直到運行的時候，列名稱中的任何錯誤才會顯現出來。此外，當開發者記不清列名是 "itemcode" 還是 "itemid" 的時候，他會發現基本的 DataSet 在這方面毫無幫助。
一個強類型的DataSet可以解決這些問題。而一個普通的DataRow卻無法取代它，因為普通的DataRow只有一個（例如）作為OrderDetailDataTable一部分的OrderDetailDataRow。您可以將這些列作為OrderDetailDataRow的實際屬性 (row.ItemCode) 進行引用。用這種方式，可以提高 IntelliSense 的生產率。表名稱和列名稱在屬性編輯器中也會變得有效，從而增強諸如數據綁定之類的設計人員級工具。
那麼，怎樣構建這個提高生產率的強類型DataSet呢？要花費如此多的時間或精力來構建一個您還沒有體驗到任何凈生產效率的東西嗎？Informix ADO.NET 驅動程序可能沒有其他一些驅動程序那麼復雜。Microsoft 的SQLDataAdapter（用於 SQL Server）包括一個 Generate DataSet 向導。而IfxDataAdapter沒有這樣的向導。不過，您可以構建一些工具來幫助您，也可以使用一些已在 .NET 框架中構建的工具。最後，您將擁有封裝所有資料庫交互的強類型DataSet的一個子代。
.NET 框架包括一個 XSD 編譯器 (xsd.exe)，它可以從某個經過特殊格式化的 .xsd 文件中生成一個強類型DataSet。但是，誰想鍵入一串 XML 呢？幸運的是，DataSet對象包括一個叫做WriteXmlSchema()的方法。此方法允許您使用非類型化的DataSet為強類型DataSet創建 XSD 文件。讓我們來看一下如何做到這一點。以下是一個示例表：
清單6.Clientstest表
CREATETABLEclientstest(clientcodeSERIALnotnull,clientacctnameCHAR(60)notnull,primarycontactCHAR(30)notnull,primaddrcodeCHAR(10),createdateDATE,initialamtDECIMAL(18,0));
以下是用於此表的單表DataSet：
清單7.定義DataSet
DS=newDataSet("dsClients");//=newDataTable("clients");DataColumnCollectioncols=mainTable.Columns;DataColumncolumn=cols.Add("clientcode",typeof(Int32));column.AllowDBNull=false;cols.Add("clientacctname",typeof(String)).MaxLength=60;cols.Add("primarycontact",typeof(String)).MaxLength=30;cols.Add("primaddrcode",typeof(String)).MaxLength=10;cols.Add("initialamt",typeof(Decimal));cols.Add("createdate",typeof(System.DateTime));//primarykeymainTable.PrimaryKey=newDataColumn[]{cols["clientcode"]};//addtabletoDataSetDS.Tables.Add(mainTable);//WriteschematofileDS.WriteXmlSchema("dsClients.xsd");
在這個定義中，可以在數據上設置類型和限制條件。還可以設置列名稱。這些名稱不必與資料庫的列名稱匹配。觀察本文下載部分中的代碼文件，以查看得到的 dsClients.xsd 文件。
為了使生成 XSD 文件（或者在發生更改後重新生成它）變得更容易，可以為這些DataSetBuilders 構建一個框架。（完成此任務所需的所有代碼都包含在下面部分。）在想用該框架確定要構建哪些 Builders 時，可以使用反射來動態確定某一 Builders 是否是DataSetBuilder。讓我們從編寫IBuildable介面開始。它定義了DataSetBuilder必須實現的屬性和方法。
清單8.IBuildable介面
publicinterfaceIBuildable{stringFileName{get;set;}stringFilePath{get;set;}LoggerLog{get;set;}DataSetDS{get;set;}voidBuildXSD();voidCompileXSD(stringoutputDirectory);}
『肆』 如何將informix資料庫的dat數據表導入到sql server或access中。我沒有安裝informix.
先要安裝一個informix客戶端,然後到控制面板-管理工具-odbc管理器里建一個數據源,安裝客戶端後,建數據源時才能有informix的選項,要用戶名密碼及服務名等一些東西,測試連接通過建好後,到sqlserver的dts導入到處工具里,在源資料庫里選擇odbc驅動程序,然後在下面的數據源選項的下拉列表裡就會有你剛建的數據源,然後下一步,開始進入sqlserver選擇導到哪裡,接下來的東西就是很簡單的了.