系统提示“Not a table DBF”后如何处理？

这个问题同样是可能发生在意外停电或非法关机或死机状态下。只是破坏的是数据库文件本身，而不是索引文件。在我们解决问题之前，我们不妨先来看一个数据库文件的结构。以Issucard.dbf为例。

当库记录为空时，其文件头格式为：

00000000h：03 00 07 19 00 00 00 00 A1 01 6F 00 00 00 00 00

当库记录不为空又出错时，文件头格式为：

00000000h：03 00 07 1B 8D 2F 00 00 A1 01 6F 00 00 00 00 00

我们不难看出，除划线部分相同而又不空外，还有3个字节不相同，当我们试着改变其中任意一个字节，就会找出一个规律：当第6个字节以16进制算法减1时，数据库就少一条记录；当第6个字节减少到00时，再将第5个字节按16进制算法减1，数据库也少一条记录；当第4个字节按16进制算法减1时，数据库少16条记录。以上出错的数据库在将第4个字节改为8C时，库文件恢复正常。

由此可以判断，当数据库在遭到意外来不及正常关闭时，其前一条记录保存是正常的。因此，我们只需将第5或者第6个字节按16进制算法减1，即可将破坏的数据库文件恢复。

上图为issucard.dbf库有两条记录的正确库示意图，解剖其各字节含义如下：00000000h00(库标志)，00000000h01-03(记录最后访问年-月-日)，00000000h04-07(记录条数)，00000000h08-09(记录起始位’141’),00000000h0a(单条记录长度)，00000020h0b-0c(字段类型及起始位)，00000030h00(字段长度)，00000140h00(记录起始标志’0D’),000001c0h0a(记录终止位)，000001c0h0b(记录终止标志’1A’)。记录条数=（记录终止位-记录起始位）/单条记录长度。