新的数据类型是如何影响 DBF 文件的

　　你也许会对VFP是如何在表中实现这些新的数据类型感兴趣。DBF结构并不允许可变长度的字段，因此事实上在DBF表里的 Varchar 和 Varbinary 字段其实是被填补上空格的。因此，Microsoft 已经有了一种跟踪 Varchar 和 Varbinary 字段的长度的机制，以保证当需要的时候返回经过正确的 Trim 的值。这里是它的工作方式：

　　× 在所有版本 VFP 的DBF表中，如果其中某个字段可以接受 Null 值，那么这个表都会被增加一个隐藏的字段，名叫 _NullFlags。该字段中包含一个位值（bit value），用于指示在一条指定记录中的某个特定字段是否包含着一个 Null。例如，如果在一条记录中的第一个可接收 null 的字段中包含一个 null，那么 _NullFlags 中的位0就被设置为1。如果第二个可接收 null 值的字段中包含一个非 null 值，那么 _NullFlags 中的位1就被设置0。由于一个字节中有8位，_NullFlag 中值的宽度为可接收 null 值字段的数量处以8。

　　× 在 VFP 9 中，_NullFlags 服务于两个责任：它的位还指示在 Varchar 和 Varbinary 字段中的值是否将字段填满了。如果一个位包含0，则在一个字段中值的长度等于该字段的长度（这个字段是满的）。如果这个位包含1，则值的长度小于字段的长度，这种情况下字段根据需要会被用空格填补，而且最后一位包含着字段的长度。例如，一个包含着“AB”这样内容的10位长度的Varchar 字段中，实际上包含的是“AB”后面跟上7个空格、再加上一个 CHR(2)（2代表值的长度），同时在 _NullsFlags 中该字段的位为1。

　　×如果一个字段既可以接收 null 值又是 Varchar 或者 Varbinary 类型的，那么会用两位来表示一个字段。低的那位代表“满”状态、而高的那位代表 null 状态。例如，一个可接收 null 的10位Varchar字段中包含着“AB”，它在 _NullFlags 中就用 01 来代表（0意味着不为 null，1意味着不满），而同一个字段中如果是一个 null 值则用11来表示（null并且不满）。

　　这里是一个示例，用于演示 _NullFlags 在用于可接收 null 的字符型（Field3）、不能为 null 的 Varchar(Field2)、可以为 null 的 Varchar 字段（Field4）的情况下的各种值。位0代表 Field2 的“满”状态，位1包含着 Field3 的 null 状态，位2包含着Field4的“满”状态，而位3包含着 Field4 的 null 状态。这个示例使用 VFP 自带的 HexEdit 工具来展示 DBF 文件中的 binary 内容。滚动到地址 000001C0 来察看表中这7条记录的内容。

　　create table TestVarchar (Field1 C(1), Field2 V(1), Field3 C(1) null, ; Field4 V(1) null) insert into TestVarchar values ('A', 'A', 'A', 'A') && Record 20 41 41 41 41, _NullFlags 00000000 = 00 insert into TestVarchar values ('A', '', 'A', 'A') && Record 20 41 00 41 41, _NullFlags 00000001 = 01 insert into TestVarchar values ('A', 'A', 'A', '') && Record 20 41 41 41 00, _NullFlags 00000100 = 04 insert into TestVarchar values ('A', 'A', .NULL., 'A') && Record 20 41 41 20 41, _NullFlags 00000010 = 02 insert into TestVarchar values ('A', 'A', 'A', .NULL.) && Record 20 41 41 41 00, _NullFlags 00001100 = 0C insert into TestVarchar values ('A', 'A', .NULL., .NULL.) && Record 20 41 41 20 00, _NullFlags 00001110 = 0E insert into TestVarchar values ('A', '', .NULL., .NULL.) && Record 20 41 00 20 00, _NullFlags 00001111 = 0F use do home() + 'Tools/HexEdit/HexEdit' with 'TestVarchar.dbf'

　　（在代码的注释中，在记录中开头的 20 表示该记录没有被删除过，41 是字母“A”，00 指示在一个 Varchar 字段中的值的长度为0字节，因为该字段为空或者 null，而在一个字符型字段中的 20 是一个空格，指示该字段为空或者 null。）

　　Blob 字段不影响 DBF 文件的结构，因为它们会被使用跟通常的 Memo 字段一样的格式储存在一个 FPT 文件中。狐社

　　DBF 的另一个改动：如果一个表中包含有这些新数据类型中的任何一种，指示表类型的第一个位中将包含着 0x32(decimal 类型的 50)（你可以使用 SYS(2029)来返回这个值）。结果，你就不能在过去版本的 VFP 中或者用 VFP ODBC 驱动打开这个表。

　　Binary 索引

　　VFP 程序员经常会建立一个基于 DELETED() 函数的索引。这个 Tag 能得到 Rushmore 优化，因为 VFP 不需要大量访问磁盘来判定哪些记录已经被删除了；它便于从索引中查找，看起来就好像从内存的缓存中查找一样（不过，在特定条件下，这样的索引可能反而会拖慢 VFP的速度。详情请见 Chris Probst 在 FoxPro Advisor 1999年五月刊上的文章。在 FoxPro Wiki 上也有几个关于这个问题的主题；http://fox.wikis.com）。

　　由于建立在 DELETED() 或者别的逻辑表达式基础上的索引只可能包含两个值中的一个（.T.或者.F.），Microsoft 发现他们可以改变这样的一个索引被存储在 CDX 文件中的途径，结果产生了更小同时更快速的索引。于是，VFP 9 就有了一种新的索引类型：binary。

　　为了建立一个 binary 索引，请给 INDEX 命令添加 BINARY 关键字。例如：

　　index on DELETED() tag DELETED binary

　　这里是关于 binary 索引的一些细节：

　　× Binary 索引可能会是一个比正常的索引小得多的、因此也就快得多的东西。TestBinaryIndex.PRG 建立了表，其中分别建立了基于 DELETED() 的一个普通的索引和一个 binary 索引。binary 索引要比普通的那个快90％。

　　× Binary 索引唯一的用途是 Rushmore 优化。你不能在它们上面进行 SEEK、也不能对它们进行 SET ORDER。

　　× 逻辑表达式的运算结果永远不能为 null 值，不管是在建立索引的时候、还是在以后使用这个表的时候，否则会出错。

　　× 你不能在 INDEX 命令中使用 FOR、ASCENDING、DESCENDING、UNIQUE、或者 CANDIDATE 子句，并且在建立一个 binary 索引的时候不能建立一个 IDX 索引文件。

　　× 按照 VFP 帮助（“Visual FoxPro Index Types”主题）的说法，VFP 根据返回记录的数量是多余还是少于总记录数量的 3％，为一个 binary 索引建立的 Rushmore 优化位图会更快或者更慢。总之，这个限制由几个事实而决定，包括总的记录数量。象许多情况一样，你需要在实际条件下测试以判定 binary 索引将会对你的查询产生什么样的影响。另一个 VFP 帮助主题“Index Based on Deleted Records”中有着关于 VFP 在各种条件下可以怎样优化的更多信息。

　　总结

　　给 VFP 9 新增加的数据类型可以使它比过去任何时候都轻松的与象 SQL Server 这样的非本地数据库一起工作，同时也在本地表中使用它们也非常有用。如果你需要在 General 字段中存储图像的话，Blob 字段尤其有用。Binary 索引能够增强你的 SQL SELECT 语句的性能，尽管 VFP 过去就已经超速了。