除了由微軟here列出的那些。VB6可捕獲錯誤的其他原因路徑/文件訪問錯誤（錯誤75）？
10 DBEngine.CompactDatabase Dbpath, DbTempPath, "", dbEncrypt
20 Kill Dbpath
30 Name DbTempPath As DbPath
上面的代碼工作一天一天在很多設備，但隨後極爲罕見線30失敗，我接到一個電話，該數據庫丟失。
今天第一次看到這一點我和拋出的錯誤：
路徑/文件訪問錯誤（錯誤75）
不過，我不認爲任何列出的原因適用於這種情況。
當今天發生這種情況時，我重新命名了臨時文件並再次運行代碼，並再次發生錯誤。
（我認爲它只是可能有一些與硬件問題來做爲使文件的副本，花了很長的時間。）
這裏沒有足夠的信息可以說，但我的猜測是，您的KILL聲明沒有在NAME聲明運行之前完成。它從來不清楚，但似乎Windows NT文件系統可以異步執行一些文件操作（尤其是大文件），以便NTFS可以不完成KILL，即使VB6認爲它是並已轉到NAME聲明。
可能最好的辦法是在KILL之後進行一些檢查以確保文件實際上已經消失，然後開始使用NAME進行重命名。
這個問題中提出的建議。這很有趣。這似乎是唯一合乎邏輯的解釋，謝謝 – kjack
它肯定是很多程序員，不僅僅是VB6的程序員必須克服的問題。磁盤操作比程序代碼慢得多，因此經常值得編寫一個「安全」磁盤操作庫，等待並檢查它們是否已成功完成，然後再將控制權交給下一行代碼 –
我不知道爲什麼會出現這個問題，但你可以添加一個解決方法是使用DoEvents調用或編寫一個小程序來等待一兩秒鐘（或更長時間），以允許磁盤完成刪除或訪問來釋放文件。
更高級的解決方法是在調用重命名之前編寫一個函數來檢查文件是否可用。
是的，謝謝你，我想我會按照你的建議去做，或者大衛在他的評論 – kjack
如果'Kill'語句需要很長時間，則可以使用'Name DbPath As DbOldPath'，'Name DbTempPath As DbPath'，'Kill DbOldPath'。 – prprcupofcoffee
@大衛，好主意！ – kjack