database disk image is malformed

Today I was just opening up my sv.db file to check a player’s time (utime). I use WinSCP so I downloaded a temp file, opened it up in DB Browser for SQLite, found the time and closed the file. I didn’t save it, I didn’t upload it back to the server. I go eat dinner, and when I come back an hour later I try to open the sv.db file again. “Invalid file format”.

Fast forward about 20 minutes and I’ve found out that I somehow corrupted my data. From what I’ve read it can happen if you mess with the database file while it is reading or writing. Never happened to me before. I’ve tried using sqlite3 to dump it to an SQL file and put it back into a database file but the .sql file is riddled with /**** ERROR: (11) database disk image is malformed *****/ and I’ve lost my utime and playerpdata tables. Now, I did a backup of my server a week ago and I thought this wasn’t a problem, I would just upload the backup database to the server.

Of course, with my luck it turns out that I forgot to refresh the main window of WinSCP and I ended up downloading the sv.db file from the beginning of July.

I’ve searched the web and the only DIY recovery solution I’ve seen is dumping the database to a .sql file and putting it into another .db file. The only other option I’ve come across is SQLite Recovery which costs a whopping $130. I’m wondering if anyone out there has a solution to this problem. Any help is appreciated.

It is usually 1 database broken. Utime as far as I know uses playerpdata. An option would be to dump all first row data of a backup database into a file, place the corrupt database back and try recovering the value’s with that.

When I had a corrupt database I was lucky to have an alternative database filled with steamid’s that I could translate into UniqueID’s. I then transferred data from the corrupt database to a MySQL server and wrote it to a file. Then made a new sqlite file and wrote all data back.
It took me about an hour to figure out how to extract the data. 15 minutes to write the script and 20 minutes to dump all data. and… sadly it took another 30 minutes to get all data back into the database.

I’m not sure what you mean by “place the corrupt database back”. Are you saying I should try to merge the corrupt database with the first rows of my old backup?

When I had a corrupt database I was lucky to have an alternative database filled with steamid’s that I could translate into UniqueID’s. I then transferred data from the corrupt database to a MySQL server and wrote it to a file. Then made a new sqlite file and wrote all data back.
It took me about an hour to figure out how to extract the data. 15 minutes to write the script and 20 minutes to dump all data. and… sadly it took another 30 minutes to get all data back into the database.
[/QUOTE]

I don’t see how writing the corrupt database to a MySQL database would help me. If it can’t be read by the sqlite3 program itself when dumping to SQL, I don’t know how I could get more than the uncorrupt data over to a MySQL database.

Luckily one day I was looking in my database to find someone’s UTime total time and I saw that the numbers it used for the player weren’t SteamIDs or even SteamID64s and I implemented a system to transfer UTime records over to another table that indexed players by their SteamID64s. So I avoided the headache of matching UniqueIDs to SteamIDs for UTime.

My experience was that the file itself worked until data was queried from playerpdata that could not be found.(thus going over something unreadable.)

If you are at all able to get data from the corrupt database you should be happy. You cant really write corrupt data anyway because that would not be read.

Well after my automatic server restart the database file was magically uncorrupted. Honestly, I am so happy because this seemed like a major error that was going to be nearly impossible to fix.