本文原创出处 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：数据文报套接字