這個問題同樣是可能發生在意外停電或非法關機或死機狀態下。只是破壞的是數據庫文件本身，而不是索引文件。在我們解決問題之前，我們不妨先來看一個數據庫文件的結構。以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’)。記錄條數=（記錄終止位-記錄起始位）/單條記錄長度。