TN045:MFC/Database为长Varchar/Varbinary支持
备注
以下技术声明，则它在联机文档，首先包括了不更新。因此，某些过程和主题可能已过时或不正确。有关最新信息，建议您搜索议题在联机文档的索引。
使用 MFC 数据库类，这说明描述了如何检索和发送 ODBC SQL_LONGVARCHAR 和 SQL_LONGVARBINARY 数据类型。
长 Varchar/Varbinary 概述支持
ODBC SQL_LONG_VARCHAR 和 SQL_LONGBINARY 数据类型 (称为此处长数据列) 可以保存巨额数据。 可以处理此数据的 3 种方法:
绑定到 CString/CByteArray。
绑定到 CLongBinary。
请勿将它并不要手动检索并不要发送长数据值，数据库类无关。
三个方法中的每一个的优点和缺点。
long 数据列未对查询的参数支持。 对 outputColumns 只支持。
绑定到 CString/CByteArray 的长数据列
优点:
此方法很简单，了解，并且您熟悉的类一起使用。 框架提供 CFormView 为 CString 支持和 DDX_Text。 有许多与 CString 和 CByteArray 类的一般字符串或集合功能，因此，您可以控制内存分配的数量的本地表示数据值。 框架维护字段数据的旧副本在 编辑 期间或 AddNew 函数调用，这样，框架可以自动检测对数据的更改您的。
备注
因为 CString 用于处理研究字符数据和 CByteArray 设计二进制数据，建议您将字符数据 (SQL_LONGVARCHAR)。 CString和二进制数据 (SQL_LONGVARBINARY)。 CByteArray。
CString 和 CByteArray 的 RFX 函数具有允许重写分配的内存的默认大小表示数据列中检索到的值的其他参数。 注意以下函数声明中的 nMaxLength 参数:
void AFXAPI RFX_Text(CFieldExchange* pFX, const char *szName,
CString& value, int nMaxLength = 255, int nColumnType =
SQL_VARCHAR);
void AFXAPI RFX_Binary(CFieldExchange* pFX, const char *szName,
CByteArray& value,int nMaxLength = 255);
如果检索长数据列。 CString 或 CByteArray，最大值返回的数据量是，默认情况下， 255 字节。 任何此外部被忽略。 在这种情况下，框架将引发异常 AFX_SQL_ERROR_DATA_TRUNCATED。 不过，您可以显式增加 nMaxLength 到很大的值，到 MAXINT。
备注
MFC 用于 nMaxLength 的值设置 SQLBindColumn 功能的本地缓冲区。这是数据存储的本地缓冲区，并且实际上不影响 ODBC 驱动程序返回的数据量。RFX_Text 和 RFX_Binary 仅进行调用使用 SQLFetch 从后端数据库中检索数据。每个 ODBC 驱动程序中已在一次获取可由返回的数据量的不同绑定的数据。，在异常 AFX_SQL_ERROR_DATA_TRUNCATED 将引发情况下，此限制小于在 nMaxLength 设置的值可能。在这些情况下，对于使用 RFX_LongBinary 切换而不是 RFX_Text 或 RFX_Binary ，以便所有数据进行检索。
类向导将绑定 SQL_LONGVARCHAR 到 CString或 SQL_LONGVARBINARY 到您的 CByteArray 。 如果要分配多要检索所长数据列的 255 个字节，然后可以提供 nMaxLength 的显式值。
当长数据列绑定到 CString 或 CByteArray，更新字段的工作与相同，在绑定到 SQL_VARCHAR 或 SQL_VARBINARY。 在 编辑期间，那么，当 更新 调用检测到数据值的更改和正确时，将列设置为的错误和空值缓存数据值和更高版本进行比较。
绑定到 CLongBinary 的长数据列
如果长数据列可以包含多 MAXINT 字节数据，则可能应考虑检索到 CLongBinary。
优点:
为检索整个长数据列，到可用内存。
缺点:
该数据在内存中保留。 此方法为大量数据也是高成本。 必须调用绑定的数据成员的 SetFieldDirty 可以确保该字段。 更新 操作包括。
如果检索长数据列。 CLongBinary，数据库类将检查长数据列的总大小，则分配足够大 HGLOBAL 内存段保留其整个数据值。 数据库类然后检索整个数据值设置为分配的 HGLOBAL。
如果数据源不能返回长数据列的预期范围，则框架将引发异常 AFX_SQL_ERROR_SQL_NO_TOTAL。 如果尝试分配 HGLOBAL 失败，标准内存将引发异常。
类向导将绑定 SQL_LONGVARCHAR 或 SQL_LONGVARBINARY 到您的 CLongBinary 。 选择 CLongBinary 作为变量输入添加成员变量对话框。 类向导将添加 RFX_LongBinary 调用您的 DoFieldExchange 调用并递增绑定字段的总数。
若要更新长数据列值，请首先确保分配的 HGLOBAL 足以通过调用 CLongBinary的 m_hData 成员的 ::GlobalSize 保存您的新数据。 如果很小，释放 HGLOBAL 并分配一个适当的大小。 然后反映新范围的设置的 m_dwDataLength 。
否则，因此，如果 m_dwDataLength 大于您可以将数据的大小，则可以自由和重新分配 HGLOBAL，或者将其分配。 确保指示用于 m_dwDataLength实际字节数。
更新 CLongBinary 工作原理
了解是不必要的更新 CLongBinary 工作方式，例如，但可能很有用。有关如何发送长数据值到数据源，因此，如果您选择第三种方法，下述。
备注
为了在更新可以包括的 CLongBinary 字段，则必须显式调用该字段的 SetFieldDirty 。如果对一个字段的任何更改，包括设置为 null，则必须调用 SetFieldDirty。还必须调用 SetFieldNull，而第二个参数是 FALSE，标记字段作为具有值。
当更新 CLongBinary 字段，数据库类使用 ODBC 的 DATA_AT_EXEC framework 时 (请参见 SQLSetPos 的 rgbValue 参数的 ODBC 文档)。 当框架准备插入或更新语句，而不是指向包含的 HGLOBAL 该数据， CLongBinary 的 地址 设置为列的 值 和长度标志设置为 SQL_DATA_AT_EXEC。 之后，那么，当更新语句发送到数据源， SQLExecDirect 将返回 SQL_NEED_DATA。 此警报结构参数的值该列的实际上是 CLongBinary的地址。 框架调用 SQLGetData 较小的缓冲区，期望该驱动程序返回数据的实际长度。 如果该驱动程序返回二进制大对象 (BLOB) 的实际长度， MFC 根据需要重新分配尽可能多的空间获取 BLOB。 如果数据源返回 SQL_NO_TOTAL，指示它无法确定 BLOB 的大小， MFC 将创建较小块。 默认初始大小是 64K，并且，随后块将为 double 该范围;例如，第二是 128K，第三个参数为 256K，依此类推。 初始大小进行配置。
未链接:数据的检索/发送直接从与 SQLGetData 的 ODBC
此方法可以完全跳过数据库类和处理长数据列。
优点:
如果您需要，可以缓存数据到磁盘或动态确定检索的数据量。
缺点:
获得结构的 编辑 或 AddNew 支持，因此，您必须执行的基本功能编写代码 (删除 不过，工作，因为它不是列级操作)。
在这种情况下，长数据列必须在选择列表，记录集，但不应绑定到由框架。 若要实现此目的提供自己的 SQL 语句。 GetDefaultSQL 或，因为对 entity_CODECRecordset 的 打开 功能的 lpszSQL 参数和不进行绑定 RFX_ 的额外列函数调用。 ODBC 需要未绑定字段在绑定字段右侧显示，因此，添加您未绑定列或结束的列的选择列表。
备注
由于您长数据列未由框架绑定，对项目的更改不会处理与 CRecordset::Update 调用。必须创建和发送需的 SQL INSERT 和 更新 语句。