- Print
- DarkLight
- PDF
Error: Your database was damaged. Dump its data and reload it. (37) when Launching FIMS after a Server Move
Article summary
Did you find this summary helpful?
Thank you for your feedback
This message may occur when launching FIMS accompanied with error, "Last open date mismatch. 9215"
These errors occurred after repairing the database due to the paths on the old and new server being different.
Steps To Duplicate:
- Launch FIMS on server or workstation.
- Receive error: Last open date mismatch. 9215
- Click OK.
- Receive error: Error: Your database was damaged. Dump its data and reload it. (37)
Answer:
If you do have this issue, please create a support case for assistance to be sure the correct steps are taken.
This issue occurred due to the database having been repaired to the wrong path which caused corruption.
The path on the new server was N:\npo, but when the repair was done, it was repaired to N:\found which did not exist on the server and the repair utility did not give a warning about this drive not existing. It should have been repaired to N:\npo\found\dbfiles. After the repair was done, the database became unstable due to it having been repaired to a path that did not physically exist on the server.
This was resolved by starting over from a new backup and that backup was restored to the new server and then the steps in the server move guide were done again to repair the database along with other steps that were specific to the environment in which this issue occurred.
NOTE: Do not name a drive N on the server as that is the name of the share that the workstations typically use and thus can cause issues and confusion.
The path on the new server was N:\npo, but when the repair was done, it was repaired to N:\found which did not exist on the server and the repair utility did not give a warning about this drive not existing. It should have been repaired to N:\npo\found\dbfiles. After the repair was done, the database became unstable due to it having been repaired to a path that did not physically exist on the server.
This was resolved by starting over from a new backup and that backup was restored to the new server and then the steps in the server move guide were done again to repair the database along with other steps that were specific to the environment in which this issue occurred.
NOTE: Do not name a drive N on the server as that is the name of the share that the workstations typically use and thus can cause issues and confusion.
Was this article helpful?