本文原創出處 couple_xiewei@163.com，例程原代碼請發郵件索取

摘要： 本文介紹了在 Visual C++ 用 ODBC 訪問 SQL Server 數據庫的方法，包括如何在程序中動態配置 SQL Server 數據源，如何與數據源建立連接，如何得到數據庫結構信息等，并給出了示例程序。

關鍵詞： ODBC, SQL Server, 數據源

ODBC （ Open Database Connectivity ，開放數據庫連接）是由 Microsoft 定義的一種數據庫訪問標準，它提供了一種標準的數據庫訪問方法以訪問不同數據庫提供商的數據庫，其本質上是一組數據庫訪問 API 。雖然數據庫訪問有多種方法，但 ODBC 以其編程相對簡單，在實際編程中被廣泛使用。

?????? VC++ 中提供了一組封裝了 ODBC API 的 MFC ODBC 類，以減少程序代碼編寫量。在 VC++ 中使用 MFC ODBC 類訪問數據庫時，一般都是先配置或選擇已有的數據源，再構造 CDatabase 類對象，打開數據源，用該數據庫類對象和 SQL （結構化查詢語言）可以對庫進行訪問，再構造 CRecordset 類或其繼承類對象，用數據集類對象和 SQL 可以實現對庫中的表的操作。在 VC++ 中用 MFC ODBC 類操作 SQL Server 數據庫基本上也是這個思路。

1.???????? 配置數據源

在程序中根據用戶選擇動態配置數據源而不調用 ODBC 數據源管理器，對于應用程序開發有時是十分必要的。畢竟 ODBC 數據源管理器對于對數據庫不熟悉的用戶顯的復雜了，且 ODBC 數據源管理器的界面風格有可能與整個應用程序的界面風格不一致，對于嚴謹的應用程序開發者來說，這些都是不能容忍的。

配置 SQL Server 數據源時，必須有 SQL Server 服務器名和服務器中的目標數據庫名 ( 否則打開該數據源時，就會彈出配置數據源對話框或失敗 ) 。這與配置 Access 等數據庫的數據源時指定數據庫文件的路徑不同。

可以通過 ODBC API 函數 SQLBrowseConnect 得到本地所有的 SQL Server 服務器、服務器中的庫、語言信息等。其使用方法如下所示：

① 得到服務器名

??? SQLBrowseConnect(hdbc, "DRIVER={SQL Server};", SQL_NTS, BrowseResult, sizeof(BrowseResult), &BrowseResultLen);

?????? 其中 hdbc 是用 SQLAllocHandle 函數得到的連結句柄，第二個參數是指定連結屬性的輸入字符串，第三個參數是輸入字符串的長度，第四個參數是輸出字符串的指針，我們要得到的信息就存于這個字符串中，第五個參數指定輸出字符串的長度，第六個參數是實際返回字符串的長度。 BrowseResult 所指向的函數返回的字符串中含有形如 “SERVER:Server={Server_name1,Server_name2, … }” 的字符串，其中 Server_name1 、 Server_name2 就是 SQL Server 服務器名。

?????? ② 得到庫名

?????? 當用戶選定一個服務器之后，可以進一步利用 SQLBrowseConnect 函數得到服務器中存在的庫或語言信息（如果需要的話）。

SQLBrowseConnect(hdbc,"SERVER=Server_name1;UID=sa;PWD=515578;",SQL_NTS, BrowseResult, sizeof(BrowseResult), &BrowseResultLen);

其中 UID 和 PWD 是訪問該服務器的用戶名和密碼。這次 BrowseResult 所指向的函數返回的字符串中含有形如 DATABASE:Database={master,model, … } 和 LANGUAGE:Language={Arabic, Brazilian, English, … } 的字符串，其中 master 、 model 為服務器中的數據庫名。

利用這些得到信息就可以配置 SQL Server 數據源了：

SQLConfigDataSource(NULL,ODBC_ADD_DSN,"SQL Server","DSN=myDSN\0 SERVER=xhm\0DATABASE=pubs\0\0" ))

?????? 作者有幸在網上找到 Santosh Rao 編寫的 CSQLInfoEnumerator 類，該類有 EnumerateSQLServers 、 EnumerateDatabase 、 EnumerateDatabaseLanguage 三個成員函數，其封裝了 SQLBrowseConnect 函數并進行相應的字符處理，大大簡化了 SQLBrowseConnect 函數的使用。

2.???????? 與數據源建立連接

如果使用 ODBC API 函數進行連結，函數 SQLConnect 、 SQLDriverConnect 和 SQLBrowseConnect 都可以實現。其中 SQLConnect 函數用于給定所有參數直接建立與數據源的連接； SQLDriverConnect 用于給定了部分連接參數，并彈出數據源瀏覽窗口與用戶交互，獲得足夠的參數后建立與數據源的連接；而 SQLBrowseConnect 是通過迭代獲取連結參數再進行連接，其使用如前所述。

MFC 為連接數據源提供了一個數據庫類 CDatabase ，通過它我們可以非常方便地與數據源建立連結：

//m_db 是 CDatabase 的對象

//m_szUserId ， m_szPassword 是 CString 對象，為訪問數據源的用戶名和密碼

?????? CString str;

?????? str = _T("DSN=xhmtest;UID=")+m_szUserId+_T(";PWD=")+m_szPassword;

?????? if (! m_db.OpenEx(str, CDatabase::noOdbcDialog ) ){

????????????? AfxMessageBox(" 打開數據源失敗 ");

}

另外，如果我們想對數據源進行操作，就可以利用打開的 CDatabase 對象執行 SQL 語句實現。如新建一張表：

??? str = "CREATE TABLE TableDemo (Column1TEXT, Column2 NUMBER)";

??? m_db.ExecuteSQL(sSql);

3.???????? 得到數據庫的結構信息

在 VC++ 中可以單獨利用 ODBC API 獲取數據庫的結構信息，但方法非常復雜，各種參數也不易理解，且返回的結果不易獲取。 MFC 中也沒有為應用程序開發者得到數據庫結構信息而提供單獨的類。但是我們還是可以通過一些已有的方法方便地獲得數據庫的結構信息。

3.1 得到數據庫中的表

利用 ODBC API 函數 SQLTables 可以得到數據庫中的表信息，但使用不易。

在 MSDN 的 sample 中有一個 catalog 例程，它示范了如果得到一個數據庫的表信息和表中的字段信息，該程序中有兩個非常實用的類： Ctables 和 Ccolumns 。其中 CTables 繼承 CRecordset 類，通過非常巧妙的方法封裝了 SQLTables 函數，并將結果集存于 CRecordset 類，方便獲取。

在程序中我們可以這樣應用：

????????????? //m_db 是已經打開的 CDatabse 對象 ,

????????????? //m_strTableOwner 是 CComboBox 對象

?????? CTables rs(&m_db);

?????? rs.Open(NULL, NULL, NULL, "TABLE");

?????? CString strTableRef;

?????? m_combTable.ResetContent();

?????? while (!rs.IsEOF())

?????? {

????????????? strTableRef = _T("[");

????????????? if (!rs.m_strTableOwner.IsEmpty())

???????????????????? strTableRef += rs.m_strTableOwner + _T("].[");

????????????? strTableRef += rs.m_strTableName + _T("]");

????????????? m_combTable.AddString(strTableRef);

????????????? rs.MoveNext();

?????? }

?????? rs.Close();

在 CTables 對象 Open 方法第四個能數指定 “TABLE” 是指返回庫中的表，當該參數為 “SYSTEM TABLE” 時返回系統表，當為 NULL 時，返回所有表。

3.2 得到表中字段結構

?????? 得到表中字段結構有三種具體實現方式：

① 直接利用 ODBC API 函數 SQLColumn ；其實現也同樣復雜。

② 利用前面提到的封裝了 SQLColumns 函數的 CColumns 類；其使用方法與 CTables 類似，其成員變量 m_strColumnName 即為字段名

③ 利用 CRecordset 類的成員函數。 MFC 在 CRecordset 類中提供了獲取表結構信息方法，使用非常方便。（但很奇怪為什么 CDatabase 類沒有獲取庫結構信息的類方法？）

我們以利用 CRecodrset 為例簡單說明怎樣得到表結構。假設現在要得到用戶在 CComboBox 對象中所選表的所有字段名，并將它埴入一個 CListCtrl 對象（其 View 屬性被設為 Report ）的列名中去：

?????? //m_strTableOwner 和上同，為 CComboBox 對象

?????? //m_listData 為 ClistCtrl 對象

?????? CRecordset rs

?????? CODBCFieldInfo info;

CString strSQL;

?????? m_combTable.GetLBText(m_combTable.GetCurSel(), strSQL);

?????? strSQL = _T("SELECT * FROM ") + strSQL;

?????? rs.Open(Open(CRecordset::snapshot, strSQL, CRecordset::readOnly);

?????? int nColumns = rs.GetODBCFieldCount();

?????? for (int nNum = 0; nNum < nColumns; nNum++)

?????? {

????????????? prs->GetODBCFieldInfo(nNum, info);

????????????? m_listData.InsertColumn(nNum, info.m_strName, LVCFMT_LEFT, 80)

?????? }

另外，我們可以利用 CRecordSet::GetFieldValue 函數通過指定列名或列序數得到記錄集中游標所指記錄的值，通過 CRecordset::AddNew 、 CRecordset::CancelUpdate 、 CRecordset::Delete 、 CRecordset::Edit 、 CRecordset::Update 等函數操作 CRecordset 打開的表。

4.???????? 本文的例程

本文所附的例程演示了如何編程讀取局域網中 SQL Server 服務器中的數據。

點擊 SQL Server 下拉列表，選擇局域網中可以連接的 SQL Server 服務器名，再輸入選定服務器的用戶名和密碼，點擊 Database 下拉列表得到服務器中存在的數據庫。然后點配置數據源按鍵，配置數據源并和數據源并建立連接，在 Table 下拉列表欄中選擇要打開的表就可以在下面的列表中顯示表中的數據了。因為表中數據量可能比較大，程序每次只讀取 25 條記錄到內存中。

參考文獻：

[1] MSDN Library, the July 2000 release, Microsoft Corporation

[2] 劉刀桂 孟繁晶， Visual C++ 實踐與提高 - 數據庫篇，中國鐵道出版社， 2001 年

? 今天懷著虞城的心來探索打印CListCtrl的方法，可惜忙到現在被老掉牙的數據加載給絆倒。但是從中卻學到了不少新東西，以前沒有遇到過的。現在就寫出來和大家分享。 ODBC數據源與CListCtrl的連接已經算是老生常談的事情了。 1、先建立數據庫（這里以一個PrintTest為數據源名來處理，該數據庫包含一張表info，里面有四個字段，ID,NAME,GROUP,AGE，只是測試用因此隨便列出幾個字段，其中ID為數字類型，其余為文本，采用Access數據庫來建立。方法就是添加一張表，然后分別對表中填充一些數據，這里就不再講述！） 2、ODBC數據源與程序的連接 ???a.在stdafx.h文件的尾部添加#include "afxdb.h" ???b.針對于整個工程的全局函數CDatabase db; ???c.在APP文件的初始化進程中添加打開數據庫的語句 ????????? ????CWinApp::InitInstance();????//此句為系統自動生成的； ????if?(!db.IsOpen()) ????????db.Open("PrintTest;"); ????else ????????AfxMessageBox("數據庫連接失敗！"); ????AfxEnableControlContainer();????//此句為系統自動生成的； 至此，與數據庫的連接基本上完成了，也正是因為這個db.Open("PrintTest;");才有了這篇文章。 3、向記錄集(CRecordset)填充數據，在這里我們必須要談到（數據庫和記錄集對象之間的）記錄字段交換 (RFX)。（大家可以在MSDN中查閱相關信息。）現在只將步驟做一個簡述： ???a.在“類視圖”中添加類，然后選擇“MFC ODBC 使用者”； ???b.在向導中，數據源按鈕后選擇“機器數據源”選擇我們設置的ODBC數據源，這里為PrintTest；確定； ???c.在彈出的對話框中選擇info表，確定； ???d.修改類名，文件名（如果有必要的話），這里改為CInfoRS,InfoRS.h,InfoRS.cpp ???e.注意下面的選擇是“動態集”，確定。（警告關閉） 這時候你可以在類向導中看到添加的新類，CInfoRS 4、在初始化對話框的時候進行數據的讀入。 值得注意的是：我們剛才定義的是全局的變量，但是定義的語句是在APP文件中寫入的，因此在Dlg文件中調用的時候我們仍然需要去聲明一下它是全局變量，也就是對Dlg來說，它是在外部已經定義過的變量。因此在Dlg.cpp的開頭我們補充extern CDatabase db; 在BOOL CPrintListCtrlDlg::OnInitDialog()中添加 ????//?TODO:?在此添加額外的初始化代碼//注意找到該函數中的這句話，在其后添加以下代碼 ????m_cList.SetExtendedStyle(LVS_EX_GRIDLINES);??????//設置ListCtrl的風格 ????int?nWidth=110; ????m_cList.InsertColumn(0,"會員編號",LVCFMT_LEFT,nWidth*2/3); ????m_cList.InsertColumn(1,"會員姓名",LVCFMT_LEFT,nWidth); ????m_cList.InsertColumn(2,"會員組織",LVCFMT_LEFT,nWidth*3/2); ????m_cList.InsertColumn(3,"年齡",LVCFMT_LEFT,nWidth/2); ????CInfoRS?rs(&db); ????UpdateList(rs); 在這個應用程序中同樣要注意到，因為我們需要的是一張類似Access表的表格，而不是類似我的電腦的圖標形式的風格，因此我們需要在添加的ListControl的時候，將其屬性中的View設置為Report。 ?UpdateList(rs);是我們自己添加的一個函數，再此我再介紹一下使用類向導添加函數的方法。 在類視圖中，右鍵，添加->添加函數,然后添加相關參數，比如返回值類型，參數類型等，記得添加參數的時候按“添加”將其添加到參數列表中。 下面列出UpdateList的代碼： void?CPrintListCtrlDlg::UpdateList(CInfoRS&?rs) { ????int?i=0; ????CString?strID; ????rs.Open(); ????m_cList.DeleteAllItems(); ????while(!rs.IsEOF()) ????{ ????????m_cList.InsertItem(i,""); ????????strID.Format("%d",rs.m_ID); ????????m_cList.SetItemText(i,0,strID); ????????m_cList.SetItemText(i,1,rs.m_NAME?); ????????m_cList.SetItemText(i,2,rs.m_GROUP); ????????m_cList.SetItemText(i,3,rs.m_AGE); ????????rs.MoveNext(); ????????i++; ????} ????rs.Close(); } 至此這個程序基本上就編寫完成了，但是使用Ctrl+F5調試的時候出現了錯誤。錯誤具體就不再描述，只告訴解決的方法。 1、一個是CInfoRS類中一句#error Security Issue: The connection string may contain a password 解決方法：注釋掉 2、類型不匹配： ??m_cList.SetItemText(i,1,rs.m_NAME ); ??m_cList.SetItemText(i,2,rs.m_GROUP); ??m_cList.SetItemText(i,3,rs.m_AGE); 將提示rs.m_NAME,rs.m_GROUP,rs.m_AGE不能從“CStringW”轉換為“LPCTSTR” 解決方法：在類視圖中定位到CInfoRS，在其變量（藍色方塊后），隨便點一個進入。按以下方法修改： //將以下代碼： ????long????m_ID; ????CStringW????m_NAME; ????CStringW????m_GROUP; ????CStringW????m_AGE; //修改為： ????long????m_ID; ????CString????m_NAME; ????CString????m_GROUP; ????CString????m_AGE; //即將這里的CStringW替換為CString //其實可以注意到之前的一大段話：以下字符串類型(如果存在)反映數據庫字段(ANSI 數據類型的 CStringA 和 Unicode數據類型的 CStringW)的實際數據類型。這是為防止 ODBC 驅動程序執行可能不必要的轉換。如果希望，可以將這些成員更改為CString 類型，ODBC 驅動程序將執行所有必要的轉換。(注意: 必須使用 3.5 版或更高版本的 ODBC 驅動程序以同時支持 Unicode 和這些轉換)。 至此，編譯通過。 但是，隨后彈出錯誤：ODBC數據源不支持動態集 修正這個問題的方法有二： 一、在剛才添加的時候，將動態集（默認）改為快照，在這里，將不會出現錯誤。 二、令人慶幸的是我曾經做過一個例子，里面確實是使用動態集，但并沒有出現這個錯誤，于是我找到了另一個程序，再次調試通過。于是就很是郁悶。于是用斷點調試，最終確定問題是發生在rs.Open();的位置。 于是查找MSDN發現（For CRecordset, the default value is CRecordset::snapshot.翻譯：對于CRecordset默認值類對象，默認值是 CRecordset::snapshot，也就是快照模式），而我們所用的是動態集的模式。這里可以將rs.Open();改為rs.Open(CRecordset::forwardOnly);再次編譯就可以通過了。 另外可以將最初的db.Open("PrintTest;");改為db.OpenEx("DSN=PrintTest;");就可以解決問題了。這其中的奧妙就不是很清楚，只能當作經驗來和大家分享一下。也希望有知道的人能夠留言告訴我。謝謝先~！ 以下將本示例的代碼以及數據庫打包供大家學習下載！ http://www.cppblog.com/Files/mymsdn/PrintListCtrl.rar ---------------------------------------------------------------------------------------------------------------------- 有關MFC ODBC類對打開的CRecordset數據集無法進行更新操作釋疑— VC6自帶的MFC4.2中CString.Format與CRecordSet的兼容性問題 在用MFC數據庫類CDatabase和CRecordset類聲明的對像無法對打開的數據集進行編輯、添加、刪除。偶然間讓我碰到個這樣的問題讓我費了不少精神，不知道為什么數據庫能正常打開，數據集也正常Open。可是就是沒辦法進入編輯狀態，老是會彈出“記錄集只讀”的提示。 ------------------------------------------------------------------------------------------------------------------------------ ?CDatabase db; ?db.OpenEx (_T"DSN=strtab"); ?CRecordset m_Set (&db); ?m_Set.Open (AFX_DB_USE_DEFAULT_TYPE, _T"select *from strtab"); ?if (!m_Set.IsOpen ()) AfxMessageBox ("數據集沒能打開!"); ?m_Set.Edit (); -------------------------------------------------------------------------------------------------------------------------------- ?????????檢查一下自己的程序，發現不管是聲明的CDatabase對像還是通過CRecordset對像打開的記錄集都使用的是缺省參數，而在我的記憶中CDatabase::OpenEx()和CRecordset::Open()這兩個成員函數的缺省參數打開的記錄集和數據庫對像都是非只讀的。倒底是那里的問題呢？ BOOL CDatabase::OpenEx(LPCTSTR lpszConnectString, DWORD dwOptions) virtual BOOL Open(UINT nOpenType = AFX_DB_USE_DEFAULT_TYPE, ??LPCTSTR lpszSQL = NULL, DWORD dwOptions = none); ?????????我在我的程序中打開數據集的Open()處下了斷點并跟蹤進去，發現CRecordset對像的m_bUpdatable標志位最初始一直是為TRUE，即可更新狀態。隨后進入了如下一串令人眼花繚亂的函數調用里，終于找到m_bUpdatable的值在那里被更改，這一切的問題出自那里！ ----------------------------------------------------------------------------------------------------------------------------------------------- BuildSQL(lpszSQL); if ((m_bUpdatable || m_bAppendable) && !IsRecordsetUpdatable()) if (!IsSQLUpdatable(m_strSQL)) return IsSelectQueryUpdatable(lpszSQL); lpchTokenFrom = FindSQLToken(strSQL, _afxFrom); //AFX_STATIC_DATA const TCHAR _afxFrom[] = _T(" FROM "); lpszFoundToken = _tcsstr(lpszFoundToken + nTokenOffset, lpszSQLToken); -------------------------------------------------------------------------------------------------------------------------------------------------- ?????????上面這每一行是跟蹤進去的函數，藍色字是函數名。這些函數是分析傳遞進來的SQL語句的并進行相應的設置來打開數據集。注意第五行_afxFrom的值是什么！這是MFC定義的一個常量，它的訂義在注釋那里。問題就在這里了，MFC定義這個常量用來分析SQL語句中是否包含用FROM關鍵字以及其后的表名，要有這個關鍵字那么數據集才是以可更新的狀態打開的。但是，很明顯我的程序中打開數據集用的SQL語句是有這個FROM關鍵字和表名的。那么我應該得到一個可更新的數據集才對啊，為什么我不能更新呢？仔細看看MFC定義的這個_afxFrom常量，它的值是_T(" FROM ")FROM的前后各有一個空格，因此真相大白了。問題就是我的SQL語句因為要返回所有的字段，就沒有給出字段名而是直接用*號表示要返回所有字段，而這個*號緊挨著FROM關鍵字，所以在最后一行中MFC用_tcsstr()函數在SQL語句中查找_afxFrom，結果是永遠也找不到MFC定義的這個兩頭各有一個空格的FROM關鍵。_tcsstr()返回一個空指針，接著這些函數一路返回FALSE，這樣m_bUpdatable的值就為FALSE，我所打開的數據集也是不可更新數據集。 ?????????這樣的問題為什么以前沒有出現呢？那是因為以前我要不是只返回特定的字段，構造好的SQL語句中的FROM也是同樣前后都有空格。就是直接CRecordset::Open()一個參數不帶的執行這個Open()函數。這樣由MFC自行構造的缺省SQL語句肯定是符合他自己的要求。 ?????????實際上，我這樣的*號緊挨FROM的SQL語句寫法也是很多人的習慣。所以，我相信也有不少的朋友也碰到這樣的問題。 ------------------------------------------------------------------------------------------------------------------- 今天我在BBS的VC版上轉悠，看到由個哥們出了這樣的問題： 說他在編寫MFC的數據庫程序(ODBC)的時候出現了錯誤，再插入新記錄后調用Update的時候出現了Assert，由于再BBS上，我和他通過信息交流了一下，發現他在AddNew和Update之間調用了Format。直覺告訴我問題出在這里。 于是分析了一下。這個是我在BBS上發的帖子。 這個問題我仔細看了一下，問題出在MFC內部：下面所述僅適用于VC6帶的MFC4.2 我們在使用ODBC進行數據庫的插入操作時，都是這么一個流程： AddNew() //給成員賦值 Update() 而在MFC的源文件dbcore.cpp 1040行，有這樣一行注釋： // Buffer address must not change - ODBC's SQLBindCol depends upon this 由于MFC在進行默認的數據源綁定時，使用CString綁定字符串型的成員，而CString使用的是動態的內存管理方式，因此這個緩沖區地址其實是可以改變的，因此，在dbcore.cpp的1041行開始便是這樣幾句： void* pvBind; pvBind = value.GetBuffer(0); value.ReleaseBuffer(); if (pvBind != pInfo->m_pvBindAddress) { ?? TRACE1("Error: CString buffer (column %u) address has changed!\n", ?? nField); ?? ASSERT(FALSE); } 因此，如果你在調用AddNew和Update之間把CString的緩沖區移動了，對不起，你必須收到一個ASSERT。(Nickshen好像就是這里的問題吧) 這樣問題就很清楚了，就是在你調用AddNew和Update之間不能移動緩沖區。但是據我和nickshen私下討論的結果，他只是在其中調用了CString的成員Format，想要把一個浮點數轉換成字符串，如果這么做就會有問題，但是直接賦值就不會，難道Format會移動CString的緩沖區？ 于是我跟蹤了一下CString的Format函數，發現在被Format函數調用的FormatV函數的流程是這樣的：先根據格式串算出大約格式化之后的字符串要占多大的空間，然后就是看是否分配新的緩沖區，然后sprintf。這個學過數據結構的都可以理解。遠離很簡單，但是有這么一個問題：在FormatV函數中，有這么一段 (strex.cpp, 659行起) case 'f': ? va_arg(argList, DOUBLE_ARG); ? nItemLen = 128; // width isn't truncated ? // 312 == strlen("-1+(309 zeroes).") ? // 309 zeroes == max precision of a double ? nItemLen = max(nItemLen, 312+nPrecision); ? break; 這個是Format對于格式串中的%f的處理，在一個switch塊中。 switch之后， // adjust nMaxLen for output nItemLen ? nMaxLen += nItemLen; ... GetBuffer(nMaxLen); 看到了沒？如果你使用了%f，MFC會很保守地認為你的一個%f會占用312的字符的位置(的確夠保守的，至于為何時312，注釋說得很清楚)，于是用這個巨大的數調用GetBuffer。 然后是CString的operator=(LPCTSTR)，這個就簡單多了，不用保守的計算，源字符串有多少個字符就分配多少個字節，同樣通過GetBuffer。 在GetBuffer的實現中，簡單的說就是看看原來的長度夠不夠，不夠重新分配一塊夠大的，然后memcpy，于是，緩沖區移動了。 慢著！ 如果說長度不夠就要移動緩沖區，而且兩種操作都會移動緩沖區，那么為何只有Format會出錯，賦值不會？ 誰說不會？你嘗試賦給你的變量一個長度超過256的字符串試試，肯定出錯，我試過了。 那么，這個256又是何處來的？你在用一個RecordSet第一步一定是Open吧。跟蹤一下發現，Open中有一步是BindFieldToColumns (dbcore.cpp 3854)，經過一系列的分發，程序到了dbrfx.cpp 777: case CFieldExchange::BindFieldToColumn: ... // Constrain to user specified max length, subject to 256 byte min if (cbColumn > (UINT)nMaxLength || cbColumn < 256) ??? cbColumn = nMaxLength;// Set up binding addres void* pvData; value.GetBufferSetLength(cbColumn+1); pvData = value.LockBuffer();??? // will be overwritten if UNICODE 那么這個nMaxLength是多少呢？這個看看AfxDB.h中對于RFX_Text的聲明，255！ 明白了？ 這么一說事情就很清楚了，所有的一切都是由于MFC內部造成的，由于我們大多數時候都不會像數據庫中插入一個長度超過255的字符串(事實上Access和SQL Server都只支持最多255個字符)，因此不會有問題，但是偏偏MFC的工程師們在做Format函數的時候保守了，于是，只要你用了%f格式符，就有問題無疑了。 知道了原因，解決方案就很簡單了： 1、如果你可以改數據庫，不妨把那個string(varchar)類型的字段改成double。 2、如果你沒有這個權限，或者數據太多已經不能改了，那么只有退而求其次，先定義一個buffer，sprintf一下，然后賦值給CString。 的確很麻煩。 同樣的程序，再VC7下調試沒有問題，有空再跟蹤一下看看吧。MFC7.1的CString已 經完全重寫了... 引用自：菜鳥心情—————C.ZHANG`s Mind—————

現象

CAsyncSocket Socket;
UINT Thread(LPVOID)
{
       Socket.Close ();
       return 0;
}
void CTestSDlg::OnOK() 
{
       // TODO: Add extra validation here
       Socket.Create(0);
       AfxBeginThread(Thread,0,0,0,0,0);
}

其中Socket對象在主線程中被調用，在子線程中被關閉。

跟蹤分析

這個問題的原因可以通過單步跟蹤(F11)的方法來了解。我們在Socket.Create(0)處設斷點，跟蹤進去會發現下面的函數被調用：

void PASCAL CAsyncSocket::AttachHandle(
          SOCKET hSocket, CAsyncSocket* pSocket, BOOL bDead)
{
    _AFX_SOCK_THREAD_STATE* pState = _afxSockThreadState;
    BOOL bEnable = AfxEnableMemoryTracking(FALSE);
    if (!bDead)
    {
             ASSERT(CAsyncSocket::LookupHandle(hSocket, bDead) == NULL);
             if (pState->m_pmapSocketHandle->IsEmpty())
             {
                  ASSERT(pState->m_pmapDeadSockets->IsEmpty());
                  ASSERT(pState->m_hSocketWindow == NULL);
                  CSocketWnd* pWnd = new CSocketWnd;
                  pWnd->m_hWnd = NULL;
                  if (!pWnd->CreateEx(0, AfxRegisterWndClass(0),
                                   _T("Socket Notification Sink"),
                                 WS_OVERLAPPED, 0, 0, 0, 0, NULL, NULL))
                 {
                       TRACE0("Warning: unable to create socket notify window!\n");
                       AfxThrowResourceException();
                 }
                 ASSERT(pWnd->m_hWnd != NULL);
                 ASSERT(CWnd::FromHandlePermanent(pWnd->m_hWnd) == pWnd);
                 pState->m_hSocketWindow = pWnd->m_hWnd;
            }
            pState->m_pmapSocketHandle->SetAt((void*)hSocket, pSocket);
    }
    else
    {
           int nCount;
           if (pState->m_pmapDeadSockets->Lookup((void*)hSocket, (void*&)nCount))
                     nCount++;
           else
                     nCount = 1;
           pState->m_pmapDeadSockets->SetAt((void*)hSocket, (void*)nCount);
   }
   AfxEnableMemoryTracking(bEnable);
}

在這個函數的開頭，首先獲得了一個pState的指針指向_afxSockThreadState對象。從名字可以看出，這似乎是一個和線程相關的變量，實際上它是一個宏，定義如下：

#define _afxSockThreadState AfxGetModuleThreadState()

我們沒有必要去細究這個指針的定義是如何的，只要知道它是和當前線程密切關聯的，其他線程應該也有類似的指針，只是指向不同的結構。

在這個函數中，CAsyncSocket創建了一個窗口，并把如下兩個信息加入到pState所管理的結構中：

    pState->m_pmapSocketHandle->SetAt((void*)hSocket, pSocket);
    pState->m_pmapDeadSockets->SetAt((void*)hSocket, (void*)nCount);
    pState->m_hSocketWindow = pWnd->m_hWnd;
    pState->m_pmapSocketHandle->SetAt((void*)hSocket, pSocket);

當調用Close時，我們再次跟蹤，就會發現在KillSocket中，下面的函數出現錯誤:

    void PASCAL CAsyncSocket::KillSocket(SOCKET hSocket, CAsyncSocket* pSocket)
    {
            ASSERT(CAsyncSocket::LookupHandle(hSocket, FALSE) != NULL);

我們在這個ASSERT處設置斷點，跟蹤進LookupHandle，會發現這個函數定義如下：

CAsyncSocket* PASCAL CAsyncSocket::LookupHandle(SOCKET hSocket, BOOL bDead)
{
     CAsyncSocket* pSocket;
     _AFX_SOCK_THREAD_STATE* pState = _afxSockThreadState;
     if (!bDead)
     {
             pSocket = (CAsyncSocket*)
             pState->m_pmapSocketHandle->GetValueAt((void*)hSocket);
             if (pSocket != NULL)
                  return pSocket;
    }
    else
    {
             pSocket = (CAsyncSocket*)
                  pState->m_pmapDeadSockets->GetValueAt((void*)hSocket);
             if (pSocket != NULL)
                   return pSocket;
    }
    return NULL;
}

顯然，這個函數試圖從當前線程查詢關于這個 socket的信息，可是這個信息放在創建這個socket的線程中，因此這種查詢顯然會失敗，最終返回NULL。

有人會問，既然它是ASSERT出錯，是不是Release就沒問題了。這只是自欺欺人。ASSERT/VERIFY都是檢驗一些程序正常運行必須正確的條件。如果ASSERT都失敗，在Release中也許不會顯現，但是你的程序肯定運行不正確，啥時候出錯就不知道了。

如何在多線程之間傳遞socket

有些特殊情況下，可能需要在不同線程之間傳遞socket。當然我不建議在使用CAsyncSOcket的時候這么做，因為這增加了出錯的風險（尤其當出現拆解包問題時，有人稱為粘包，我基本不認同這種稱呼）。如果一定要這么做，方法應該是：

1. 當前擁有這個socket的線程調用Detach方法，這樣socket句柄和C++對象及當前線程脫離關系
2. 當前線程把這個對象傳遞給另外一個線程
3. 另外一個線程創建新的CAsyncSocket對象，并調用Attach

上面的例子，我稍微做修改，就不會出錯了：

CAsyncSocket Socket;
UINT Thread(LPVOID sock)
{
         Socket.Attach((SOCKET)sock);//如果在線程外close()，記得在離開時Detach().
         Socket.Close ();
         return 0;
}
void CTestSDlg::OnOK() 
{
         // TODO: Add extra validation here
         Socket.Create(0);
         SOCKET hSocket = Socket.Detach ();
         AfxBeginThread(Thread,(LPVOID)hSocket,0,0,0,0);
}
引用自：馨榮家園

----------------------------------------------------------------------------------------------------

本文以及另外兩篇相關文章解釋 Windows Sockets 
編程方面的一些問題。本文介紹阻塞。其他問題包含在 Windows Sockets：字節排序和 Windows Sockets：轉換字符串文章中。 
如果使用 CAsyncSocket 類或從其派生，則您需要自己管理這些問題。如果您使用 CSocket 
類或從其派生，則由 MFC 管理它們。阻塞 
套接字可以處于“阻塞模式”或“無阻塞模式”。處于阻塞（或同步）模式時，套接字的函數直到可以完成自己的操作時才返回。這稱為“阻塞”，因為函數被調用的套接字在調用返回前無法執行任何操作──它被阻塞了。例如，對 
Receive 成員函數的調用可能需要任意長的時間才能完成，因為它要等待發送應用程序來發送（使用 CSocket 或使用帶阻塞的 
CAsyncSocke 即是如此）。如果 CAsyncSocket 
對象處于無阻塞模式（異步操作），調用會立即返回，而當前錯誤代碼（可使用 GetLastError 成員函數檢索）為 WSAEWOULDBLOCK 
，它指出由于模式的原因，調用若不立即返回則將阻塞。（ CSocket 永遠不返回 WSAEWOULDBLOCK 
。該類為您管理阻塞。） 
在 32 位操作系統（如 Windows 95 或 Windows 98）和 16 位操作系統（如 
Windows 3.1）下，套接字的行為是不同的。與 16 位操作系統不同，32 位操作系統使用搶占式多任務處理技術并提供多線程運行方式。在 32 
位操作系統下，可以將套接字放在單獨的輔助線程中。線程中的套接字可以在不妨礙應用程序中其他活動的情況下阻塞，并且不必在阻塞上花費計算時間。有關多線程編程的信息，請參見文章多線程編程。 

注意: 在多線程應用程序中，可以使用 CSocket 
的阻塞特性來簡化程序設計，而不影響用戶界面的響應。通過處理主線程中的用戶交互和備用線程中的 CSocket 
處理，可以將這些邏輯操作分開。在非多線程的應用程序中，這兩個活動必須合并為單個線程來處理。這通常意味著使用 CAsyncSocket 
以根據需要處理通信請求，或重寫 CSocket::OnMessagePending 以在漫長的同步活動中處理用戶操作。 
? 
其余的討論針對以 16 位操作系統為目標的程序員： 
通常，如果使用的是 CAsyncSocket 
，則應避免使用阻塞操作，而應使用異步操作。例如，在異步操作中，從調用 Receive 后接收到 WSAEWOULDBLOCK 
錯誤代碼那一刻開始，您將一直等到 OnReceive 成員函數被調用以通知您可以再次讀取。通過回調套接字的適當回調通知函數（如 
OnReceive）來完成異步調用。 
在 Windows 下，阻塞調用被認為是錯誤的做法。默認情況下，CAsyncSocket 
支持異步調用，而且您必須使用回調通知自己管理阻塞。另一方面，CSocket 類是同步的。它抽取 Windows 消息并為您管理阻塞。 
有關阻塞的更多信息，請參見 Windows Sockets 規范。有關“On”函數的更多信息，請參見 
Windows Sockets：套接字通知和 Windows Sockets：從套接字類派生。 
本文以及另外兩篇相關文章解釋 Windows Sockets 
編程方面的一些問題。本文介紹轉換字符串。其他問題在 Windows Sockets：阻塞和 Windows Sockets：字節排序中介紹。 
如果使用 CAsyncSocket 類或從其派生，則您需要自己管理這些問題。如果您使用 CSocket 
類或從其派生，則由 MFC 管理它們。轉換字符串 
如果在使用以不同的寬字符格式（如 Unicode 或多字節字符集 
MBCS）存儲的字符串的應用程序間通信，或在這些應用程序與使用 ANSI 字符串的應用程序間通信，您必須使用 CAsyncSocket 
自己管理轉換。和 CSocket 對象一起使用的 CArchive 對象通過 CString 
類的功能管理此轉換。有關更多信息，請參見位于 Platform SDK 中的 Windows Sockets 規范。 
Windows Sockets：使用 CAsyncSocket 類
http://tech.163.com/school · 
2005-10-09 16:08:40 · 來源: MSDN
? 
本文介紹 CAsyncSocket 類的用法。請注意，該類在非常低的級別上封裝 Windows 
Sockets API。 CAsyncSocket 
適合那些對網絡通信細節很了解，但希望利用回調的便利通知網絡事件的程序員使用。基于該假定，本文僅提供基本說明。如果想利用 Windows Sockets 
方便地處理 MFC 應用程序中的多個網絡協議，而又不想放棄靈活性，可以考慮使用 CAsyncSocket 
。您可能也會感覺到，自己直接編寫通信程序要比使用 CSocket 類的通用替換模型效果更好。 
“MFC 參考”中對 CAsyncSocket 進行了描述。Visual C++ 
也提供了位于 Platform SDK 中的 Windows Sockets 規范。具體細節由您決定。Visual C++ 不提供 
CAsyncSocket 的示例應用程序。 
如果您對網絡通信不是很了解，希望獲得一個簡單的解決方案，請使用帶 CArchive 對象的 
CSocket 類。有關更多信息，請參見 Windows Sockets：使用帶存檔的套接字。 
本文包括： 
創建和使用 CAsyncSocket 對象。 
您具有的 CAsyncSocket 責任。 
創建和使用 CAsyncSocket 對象 
? 
使用 CAsyncSocket 
構造一個 CAsyncSocket 對象并使用該對象創建基礎 SOCKET 句柄。 
? 
套接字的創建遵循兩階段構造的 MFC 模式。 
例如： CAsyncSocket 
sock;sock.Create( ); // Use the default parameters 
- 或 - 
CAsyncSocket* 
pSocket = new CAsyncSocket;int nPort = 27;pSocket-> Create( nPort, SOCK_DGRAM 
); 
上面的第一個構造函數在堆棧上創建一個 CAsyncSocket 
對象，第二個構造函數在堆上創建 CAsyncSocket 。上面的第一個 Create 調用使用默認參數創建流式套接字，第二個 
Create 調用創建具有指定端口和地址的數據文報套接字。（任一個 Create 版本都可以和任一種構造方法一起使用。） 
Create 的參數有： 
“端口”：短整型。 
? 
對于服務器套接字，必須指定端口。對于客戶端套接字，通常接受此參數的默認值，該值允許 Windows 
Sockets 選擇端口。 
套接字類型： SOCK_STREAM （默認值）或 SOCK_DGRAM 。 
套接字“地址”，如“ftp.microsoft.com”或“128.56.22.8”。 
? 
該地址為網絡上的網際協議 (IP) 地址。很可能要始終依賴此參數的默認值。 
? 
關于術語“端口”和“套接字地址”的解釋見 Windows Sockets：端口和套接字地址。 

如果套接字是客戶端，則使用 CAsyncSocket::Connect 將此套接字對象連接到服務器套接字。 
? 
- 或 - 
如果套接字是服務器，則將套接字設置為開始偵聽（使用 
CAsyncSocket::Listen）來自客戶端的連接嘗試。接收到連接請求時，用 CAsyncSocket::Accept 接受該請求。 
接受連接后，可以執行驗證密碼等任務。 
注意 Accept 成員函數采用對新的空 CSocket 對象的引用作為它的參數。在調用 
Accept 之前，必須構造該對象。如果此套接字對象超出范圍，則連接關閉。不要對這個新套接字對象調用 Create 
。有關示例，請參見文章 Windows Sockets：操作順序。 
通過調用 CAsyncSocket 對象的封裝 Windows Sockets API 函數的成員函數，與其他套接字進行通信。 
? 
請參見“MFC 參考”中的 Windows Sockets 規范和 CAsyncSocket 類。 

銷毀 CAsyncSocket 對象。 
? 
如果在堆棧上創建了套接字對象，當包含函數超出范圍時將調用此對象的析構函數。如果使用 new 
運算符在堆上創建了套接字對象，則您必須負責使用 delete 運算符銷毀此對象。 
析構函數在銷毀對象之前調用對象的 Close 成員函數。 
? 
有關代碼中該順序的示例（實際上是對于 CSocket 對象），請參見 Windows 
Sockets：操作順序。您對 CAsyncSocket 的責任 
創建 CAsyncSocket 類的對象后，該對象封裝 Windows SOCKET 
句柄并提供對此句柄的操作。使用 CAsyncSocket 時，如果您直接使用 API，則必須處理可能面對的所有問題。例如： 
“阻塞”方案。 
發送和接收計算機之間的字節順序差異。 
在 Unicode 和多字節字符集 (MBCS) 字符串之間轉換。 
? 
有關這些術語的定義和其他信息，請參見 Windows Sockets：阻塞、Windows Sockets：字節排序和 Windows Sockets：轉換字符串。 
盡管存在這些問題，但如果應用程序需要您能獲得所有的靈活性和控制能力， CAsycnSocket 
類可能是正確的選擇。如果應用程序沒有這種需求，可考慮使用 CSocket 類。 CSocket 
向您隱藏大量詳細信息：它在阻塞調用期間抽取 Windows 消息并賦予您訪問 CArchive 的權限，而 CArchive 
為您管理字節順序差異和字符串轉換。 
有關更多信息，請參見： 
Windows Sockets：背景知識
Windows Sockets：流式套接字
Windows Sockets：數據文報套接字
Windows Sockets：使用帶存檔的套接字
http://tech.163.com/school · 2005-10-09 
15:22:30 · 來源: MSDN
? 
本文描述 CSocket 編程模型。CSocket 類提供了比 CAsyncSocket 
類抽象化級別更高的套接字支持。CSocket 使用 MFC 序列化協議的一種版本，通過 MFC CArchive 
對象將數據傳遞給套接字對象，或者從套接字對象傳出數據。CSocket 提供阻塞（同時管理 Windows 消息的后臺處理），并賦予您訪問 
CArchive 的權限，而 CArchive 則管理著必須由您自己使用原始 API 或 CAsyncSocket 
類來管理的通信的許多方面。 
提示:可以單獨使用 CSocket 類作為 CAsyncSocket 
的更方便版本，但最簡單的編程模型是使用帶 CArchive 對象的 CSocket。
? 
有關帶存檔的套接字實現的工作機制的更多信息，請參見 Windows 
Sockets：帶存檔的套接字的工作方式。有關示例代碼，請參見 Windows Sockets：操作順序和 Windows 
Sockets：帶存檔的套接字示例。有關通過從套接字類派生自己的類獲得的某些功能的信息，請參見 Windows Sockets：從套接字類派生。 
注意:如果正在編寫與已建立的（非 MFC）服務器通信的 MFC 客戶程序，則不要通過存檔發送 C++ 
對象。除非該服務器是一個 MFC 應用程序，它知道您要發送的對象的類型，否則服務器將無法接收和反序列化這些對象。有關與非 MFC 
應用程序通信的主題的相關材料，另請參見文章 Windows 
Sockets：字節排序。
CSocket 編程模型 
? 
使用 CSocket 對象涉及創建數個 MFC 
類對象并將它們關聯起來。在下面的一般過程中，服務器套接字和客戶端套接字都將采取每一步驟（步驟 3 除外，此步驟中每個套接字類型要求不同的操作）。 
提示:在運行時，服務器應用程序通常首先做好準備然后“偵聽”客戶端應用程序何時尋求連接。如果客戶端嘗試連接時服務器未準備好，一般需要用戶應用程序稍后再嘗試連接。
? 
設置服務器套接字和客戶端套接字之間的通信
構造一個 CSocket 對象。 
使用此對象創建基礎 SOCKET 句柄。 
? 
對于 CSocket 客戶端對象，除非需要數據文報套接字，否則通常應使用默認參數來 
Create 該對象。對于 CSocket 服務器對象，則必須在 Create 調用中指定端口。 
注意:CArchive 不適用于數據文報套接字。如果想將 CSocket 
用于數據文報套接字，必須像使用 CAsyncSocket 
那樣使用該類，即不帶存檔。因為數據文報是不可靠的（不保證送達，并且可能重復或順序不對），它們不能通過存檔與序列化兼容。而您期望序列化操作可以可靠地、按順序完成。如果試圖將帶 
CArchive 對象的 CSocket 用于數據文報，則 MFC 斷言失敗。
如果套接字是客戶端對象，則調用 CAsyncSocket::Connect 將此套接字對象連接到服務器套接字。 
? 
- 或 - 
如果套接字是服務器端對象，則調用 CAsyncSocket::Listen 
開始偵聽來自客戶端的連接嘗試。接收到連接請求時，調用 CAsyncSocket::Accept 接受該請求。 
注意:Accept 成員函數采用對新的空 CSocket 對象的引用作為它的參數。在調用 
Accept 之前，必須構造該對象。如果此套接字對象超出范圍，則連接關閉。不要對這個新套接字對象調用 
Create。
創建一個 CSocketFile 對象，將 CSocket 對象與它關聯起來。 
創建一個 CArchive 對象用于加載（接收）或存儲（發送）數據。此存檔與 CSocketFile 對象關聯。 
? 
注意:CArchive 不適用于數據文報套接字。 
使用 CArchive 對象在客戶端套接字與服務器套接字之間傳遞數據。 
? 
注意，不管是加載（接收）還是存儲（發送），給定的 CArchive 
對象只在一個方向上移動數據。某些情況下，需要使用兩個 CArchive 對象：一個用于發送數據，一個用于接收確認。 
接受連接并設置存檔后，可以執行驗證密碼之類的任務。 
銷毀存檔、套接字文件和套接字對象。 
注意CArchive 類提供了專門與 CSocket 類一起使用的 
IsBufferEmpty 
成員函數。例如，如果緩沖區包含多條數據消息，則需要一直循環到讀完所有消息和清空緩沖區。否則，下一個指示有數據要接收的通知可能會無限期延遲。使用 
IsBufferEmpty 可確保檢索所有數據。有關使用 IsBufferEmpty 的示例，請參見 CHATSRVR 
示例應用程序。有關 MFC 示例的源代碼和信息，請參見 MFC 示例。
? 
Windows Sockets：操作順序一文用示例代碼闡釋了此進程的兩端。 
Windows Sockets：背景知識
http://tech.163.com/school · 2005-10-09 14:54:00 · 
來源: MSDN
? 
本文介紹 Windows Sockets 的性質和用途。其他內容還包括： 
定義術語“套接字”。 
描述 SOCKET 句柄數據類型。 
描述套接字的用途。 
? 
Windows Sockets 規范為 Microsoft Windows 
定義了一個二進制兼容網絡編程接口。Windows Sockets 基于 Berkeley Software Distribution（BSD，4.3 版）中的 
UNIX 套接字實現，后者是美國加州大學伯克利分校開發的。該規范包括針對 Windows 的 BSD 樣式套接字例程和擴展。通過使用 Windows 
Sockets，應用程序能夠在任何符合 Windows Sockets API 的網絡上通信。在 Win32 上，Windows Sockets 提供線程安全。 

許多網絡軟件供應商支持網絡協議下的 Windows Sockets，這些協議包括：傳輸控制協議/網際協議 
(TCP/IP)、Xerox 網絡系統 (XNS)、Digital Equipment Corporation 的 DECNet 協議和 
Novell Corporation 的互聯網包交換協議/順序分組報文交換協議 (IPX/SPX) 等。雖然目前的 Windows Sockets 規范定義了 
TCP/IP 的套接字抽象化，但任何網絡協議都可以通過提供自己版本的、實現 Windows Sockets 的動態鏈接庫 (DLL) 來滿足 Windows 
Sockets。用 Windows Sockets 編寫的商用應用程序示例包括 X Windows 服務器、終端模擬器和電子郵件系統。 
注意: Windows Sockets 
的用途是將基礎網絡抽象出來，這樣，您不必對網絡非常了解，并且您的應用程序可在任何支持套接字的網絡上運行。因此，本文檔不討論網絡協議的細節內容。 
? 
Microsoft 基礎類庫 (MFC) 通過提供兩個類來支持使用 Windows Sockets 
API 進行編程。其中一個類為 CSocket ，它提供高級抽象化來簡化網絡通信編程。 
Windows Sockets 規范“Windows Sockets：用于 Microsoft 
Windows 環境下的網絡計算的開放接口”現在為 1.1 版本，它是 TCP/IP 
群體中一個由個人和公司組成的大團體開發的，是一個開放的網絡標準，可免費使用。套接字編程模型當前支持一個“通信域”，該“通信域”使用網際協議組 (Internet 
Protocol Suite)。該規范可在 Platform SDK 中獲得。 
提示: 因為套接字使用網際協議組，所以它們對于支持“信息高速公路”上 Internet 通信的應用程序是首選方式。 
套接字的定義 
? 
套接字是一個通信終結點，它是 Windows Sockets 
應用程序用來在網絡上發送或接收數據包的對象。套接字具有類型，與正在運行的進程相關聯，并且可以有名稱。目前，套接字一般只與使用網際協議組的同一“通信域”中的其他套接字交換數據。 

這兩種套接字都是雙向的，是可以同時在兩個方向上（全雙工）進行通信的數據流。 
可用的套接字類型有以下兩種： 
流式套接字 
? 
流式套接字提供沒有記錄邊界的數據流，即字節流。字節流能確保以正確的順序無重復地被送達。 
數據文報套接字 
? 
數據文報套接字支持面向記錄的數據流，但不能確保能被送達，也無法確保按照發送順序或不重復。 
? 
“有序”指數據包按發送的順序送達。“不重復”指一個特定的數據包只能獲取一次。 
注意: 在某些網絡協議下（如 XNS），流可以面向記錄，即作為記錄流而非字節流。但在更常用的 TCP/IP 
協議下，流為字節流。Windows Sockets 提供與基礎協議無關的抽象化級別。 
? 
有關上述類型以及各種套接字適用情形的信息，請參見 Windows Sockets：流式套接字和 Windows Sockets：數據文報套接字。 
SOCKET 數據類型 
每一個 MFC 套接字對象封裝一個 Windows Sockets 對象的句柄。該句柄的數據類型為 
SOCKET。SOCKET 句柄類似于窗口的 HWND。MFC 套接字類提供對封裝句柄的操作。 
Platform SDK 中詳細描述了 SOCKET 數據類型。 
套接字的用途 
套接字的作用非常大，至少在下面三種通信上下文中如此： 
客戶端/服務器模型。 
對等網絡方案，如聊天應用程序。 
通過讓接收應用程序將消息解釋為函數調用來進行遠程過程調用 (RPC)。 
提示: 最適合使用 MFC 套接字的情況是當同時編寫通信的兩端時：在兩端都使用 MFC。有關該主題（包括如何管理與非 
MFC 應用程序通信的情況）的更多信息，請參見 Windows Sockets：字節排序。 
Windows Sockets：流式套接字
http://tech.163.com/school · 2005-10-09 15:03:48 · 
來源: MSDN
? 
本文描述流式套接字，它是兩種可用的 Windows Sockets 類型中的一種。（另一種類型是數據文報套接字。） 
流式套接字提供沒有記錄邊界的數據流：可以是雙向的字節流（應用程序是全雙工：可以通過套接字同時傳輸和接收）。可依賴流傳遞有序的、不重復的數據。（“有序”指數據包按發送順序送達。“不重復”指一個特定的數據包只能獲取一次。）這能確保收到流消息，而流非常適合處理大量數據。 

網絡傳輸層可將數據拆分為或分組為若干個大小適當的數據包。 CSocket 
類將為您處理打包和解包。 
流基于顯式連接：套接字 A 請求與套接字 B 建立連接；套接字 B 接受或拒絕此連接請求。 
打電話的情況與流非常相似：正常情況下，接聽方聽到您的話和您講話時的順序一樣，沒有重復和遺漏。流套接字適合文件傳輸協議 
(FTP) 這類實現，此協議有利于傳輸任意大小的 ASCII 或二進制文件。 
如果必須保證數據送達而且數據大小很大時，流式套接字優于數據文報套接字。有關流式套接字的更多信息，請參見 
Windows Sockets 規范。該規范可在 Platform SDK 中獲得。 
MFC 示例 CHATTER和 CHATSRVR 
都使用流式套接字。這些示例可能已經設計為使用數據文報套接字向網絡上的所有接收套接字廣播。而目前的設計更好，這是因為： 
廣播模型受制于網絡“洪水”（或“風暴”）問題。 
后來采用的客戶端-服務器模型更有效。 
流式模型提供可靠的數據傳輸，數據文報模型則未提供。 
最終模型利用在 CArchive 類借給 CSocket 類的 Unicode 和 ANSI 套接字應用程序之間通信的能力。 
注意: 如果使用 CSocket 類，則必須使用流。如果將套接字類型指定為 SOCK_DGRAM ，則 MFC 
斷言失敗。 
Windows Sockets：數據文報套接字
http://tech.163.com/school · 2005-10-09 15:15:43 
· 來源: MSDN
? 
本文描述數據文報套接字，它是兩種可用的 Windows Sockets 類型中的一種。（另一種類型是 
流式套接字。） 
數據文報套接字支持雙向數據流，此數據留不能保證按順序和不重復送達。數據文報也不保證是可靠的；它們可能無法到達目的地。數據文報可能不按順序到達并且可能會重復，但只要記錄的大小沒有超過接收端的內部大小限制，就會保持數據中的記錄邊界。您負責管理順序和可靠性。（可靠性在局域網 
[LAN] 上往往很好，但在廣域網 [WAN] 如 Internet 上卻不太好。） 
數據文報為“無連接”的，也就是不建立顯式連接。可將數據文報消息發送到指定的套接字，然后從指定的套接字接收消息。 

數據文報套接字的一個示例是使網絡上的系統時鐘保持同步的應用程序。這闡釋了數據文報套接字的一個附加功能，即至少在某些設置中，向大量的網絡地址廣播消息。 

在面向記錄的數據方面，數據文報套接字優于流式套接字。有關數據文報套接字的更多信息，請參見 
Platform SDK 中的 Windows Sockets 規范。 
Windows Sockets：字節排序
http://tech.163.com/school · 2005-10-09 16:30:27 · 
來源: MSDN
? 
本文以及另外兩篇相關文章解釋 Windows Sockets 編程方面的一些問題。本文介紹字節排序。其他問題在文章 Windows Sockets：阻塞和 Windows Sockets：轉換字符串中介紹。 
如果使用 CAsyncSocket 類或從其派生，則您需要自己管理這些問題。如果您使用 CSocket 類或從其派生，則由 MFC 
管理它們。 
字節排序 
不同的計算機結構有時使用不同的字節順序存儲數據。例如，基于 Intel 的計算機存儲數據的順序與 Macintosh 
(Motorola) 計算機相反。Intel 字節順序稱為“Little-Endian”，與網絡標準“Big-Endian”順序也相反。下表解 
釋這些術語。 
Big-Endian 和 Little-Endian 字節排序 
字節排序 
含義 
Big-Endian 
最重要的字節在詞的左端。 
Little-Endian 
最重要的字節在詞的右端。
通常，您不必為在網絡上發送和接收的數據的字節順序轉換擔心，但在有些情況下，您必須轉換字節順序。 
何時必須轉換字節順序 
在下列情況中需要轉換字節順序： 
傳遞的信息需要由網絡解釋（與發送到另一臺計算機的數據相反）。例如，可能傳遞端口和地址，這些信息 
必須為網絡理解。 
與之通信的服務器應用程序不是 MFC 應用程序（并且沒有它的源代碼）。如果兩臺計算機不共享相同的字節 
排序，則需要字節順序轉換。 
何時不必轉換字節順序 
在下列情況下可以免去轉換字節順序的工作： 
兩端的計算機可以同意不交換字節，并且這兩臺計算機使用相同的字節順序。 
與之通信的服務器是 MFC 應用程序。 
有與之通信的服務器的源代碼，因此可以明確地判斷是否必須轉換字節順序。 
可以將服務器移植到 MFC。這樣做相當容易，所得到的通常是更小、更快的代碼。 
使用 CAsyncSocket 時，您必須自己管理任何必需的字節順序轉換。Windows Sockets 將“Big-Endian”字節順 
序模型標準化，并提供在該順序和其他順序之間轉換的函數。然而，與 CSocket 一起使用的 CArchive 使用相 
反的順序（“Little-Endian”），但 CArchive 為您管理字節順序轉換的細節。通過在應用程序中使用這種標準 
排序，或通過使用 Windows Sockets 字節順序轉換函數，可增強代碼的可移植性。 
最適合使用 MFC 套接字的情況是當編寫通信的兩端時：在兩端都使用 MFC。如果正在編寫將與非 MFC 應用程序 
通信的應用程序（如 FTP 服務器），則在向存檔對象傳遞數據前，您可能需要使用 Windows Sockets 轉換例程 
ntohs 、 ntohl 、 htons 和 htonl 
自己管理字節交換。本文稍后將給出這些用于與非 MFC 應用程序通信的函數 
示例。 
注意 當通信的另一端不是 MFC 應用程序時，也必須避免將從 CObject 派生的 C++ 對象以流的形式輸入存 
檔，因為接收端無法處理它們。請參見 Windows 
Sockets：使用帶存檔的套接字中的說明。 
有關字節順序的更多信息，請參見 Platform SDK 中的 Windows Sockets 規范。 
字節順序轉換示例 
下面的示例顯示使用存檔的 CSocket 對象的一個序列化函數。它還闡釋了在 Windows Sockets API 中如何使用 
字節順序轉換函數。 
該示例顯示這樣的情形：您正在編寫與非 MFC 服務器應用程序通信的客戶程序，而您沒有訪問該服務器應用程序 
源代碼的權限。在這種情況下，必須假設非 MFC 服務器使用標準的網絡字節順序。相反，MFC 客戶端應用程序對 
CSocket 對象使用 CArchive 對象，而 CArchive 
使用與網絡標準相反的“Little-Endian”字節順序。 
假設要與之通信的非 MFC 服務器具有如下已建立的消息包協議： 
struct Message { long MagicNumber; unsigned short Command; short Param1; long Param2; }; 
上述內容用 MFC 術語表示則為： 
struct Message { long m_lMagicNumber; short m_nCommand; short m_nParam1; long m_lParam2; void Serialize 


( CArchive& ar ); }; 
在 C++ 中， struct 和類在本質上是一回事。 Message 
結構可以有成員函數，如以上聲明的 Serialize 
成員函數。 
Serialize 成員函數可能為如下形式： void Message::Serialize(CArchive& ar) 
{ 
if (ar.IsStoring()) 

{ 
ar < < (DWORD)htonl(m_lMagicNumber); 
ar < < 
(WORD)htons(m_nCommand); 
ar < < (WORD)htons(m_nParam1); 
ar < 
< (DWORD)htonl(m_lParam2); 
} 
else 
{ 
WORD w; 
DWORD dw; 

ar > > dw; 
m_lMagicNumber = ntohl((long)dw); 
ar > > w ; 

m_nCommand = ntohs((short)w); 
ar > > w; 
m_nParam1 = 
ntohs((short)w); 
ar > > dw; 
m_lParam2 = ntohl((long)dw); 
} 

} 
該示例要求進行數據字節順序轉換，因為一端的非 MFC 服務器應用程序的字節排序與另一端在 MFC 客戶端應用程序中使用的 CArchive 
明顯不匹配。該示例闡釋了 Windows Sockets 提供的幾個字節順序轉換函數。下表描述了這些函數。 
Windows Sockets 字節順序轉換函數 
函數 
作用 
ntohs 
將 16 位數量從網絡字節順序轉換為主機字節順序（從 Big-Endian 轉換為 Little-Endian）。 
ntohl 
將 32 位數量從網絡字節順序轉換為主機字節順序（從 Big-Endian 轉換為 Little-Endian）。 
htons 
將 16 位數量從主機字節順序轉換為網絡字節順序（從 Little-Endian 轉換為 Big-Endian）。 
htonl 
將 32 位數量從主機字節順序轉換為網絡字節順序（從 Little-Endian 轉換為 Big-Endian）。
此示例的另一個要點是，當通信另一端的套接字應用程序為非 MFC 應用程序時，必須避免出現如下列語句的操作： 
ar pMsg; 
這里的 pMsg 是指向從 CObject 類派生的 C++ 
對象的指針。這將發送多余的與對象關聯的 MFC 信息，而服務器并不理解這些信息，因為只有服務器是 MFC 應用程序時才理解。 
有關更多信息，請參見： 
Windows Sockets：使用 CAsyncSocket 類 
Windows Sockets：使用帶存檔的套接字
Windows Sockets：背景知識
Windows Sockets：流式套接字
Windows Sockets：數據文報套接字