Lost Log File .. malformed database

[djbeam]

I am running a current version of HS3 .. and when I go to get log information, there is none.

I see error messages in the startup log that indicate

8/9/2021 4:25:59 PM ~!~Error~!~SQL Exception adding record(s) to the LOG database(0): database disk image is malformed database disk image is malformed, Code=11 SQL=

which tells me It must be regenerated . .but how to do that .... any suggestions would be greatly appreciated ??

tanx
Don

[w.vuyk]

Stop HS3 for moment. Then delete the .hsd file in your HS installation directory\Logs. Then start HS3 again, and the log should start to build up again from scratch

Wim

[djbeam]

Wim, thank you for sharing this .. but I have seen a significant # of posts for this happening with HS3 and HS4. This is the third time that I have had to kill the log file ...and it seems that I am not the only one that is repeatedly having to do this .. (HS3 and HS4) .

Any thoughts on why this is happening .. and what I need to do to fix this issue for the long term, not short term?

Don

[ServiceXp]

Windows? Running as a Service?

[w.vuyk]

Wim, thank you for sharing this .. but I have seen a significant # of posts for this happening with HS3 and HS4. This is the third time that I have had to kill the log file ...and it seems that I am not the only one that is repeatedly having to do this .. (HS3 and HS4) .

Any thoughts on why this is happening .. and what I need to do to fix this issue for the long term, not short term?

Don

djbeam

The problem I think is the fact that HST does not use SQLlite in a save way, that is with write ahead (WAL) settings. This setting can reasonably protect databases to be malformed because of a system outage or incorrect closing of HS.

If your system goes down, without properly closing HS the database will damage easily. Make sure to properly shutdown HS, before shutting down the system - Windows will not shutdown HS in a neat way when going down for installing updates.
If you can make sure HS is shutdown properly, the database will stay intact. I always make sure the system is going down in a guided way here. The last time I had a damaged log is several years ago now (knock woods )


Regards,
Wim

[djbeam]

Thanks makes sense (not operational sense but that is a code issue) .. is there any way to fix the HS3 database logfile?

[George]

Thanks makes sense (not operational sense but that is a code issue) .. is there any way to fix the HS3 database logfile?

Sorry, but I got bite by that a couple of times before I got twice shy. In HS1, I could safely just erase or rename the log file and it would just create a new one the next time it wrote it. For HS3, you will get very bad things happen if the log file gets renamed/deleted/mangled while HS3 is running. And not just to the log file but to other data bases as well.

Yes, there is an easy way (in mainframe days we called it adding armor) that a couple of lines of code could prevent it.. But as HS3 is dead and buried with it's code shriveled to dust by now, no one it holding their breath.

I just make sure that I shutdown HS3 before I rename/erase or mess with any of it's files. Sorry.