The database disk image is malformed.

[tobject]

How do I fix "The database disk image is malformed." thingy?

[seandisanti]

How do I fix "The database disk image is malformed." thingy?

do you have a hammer? or perhaps a little more info about the "thingy"

[tobject]

SQLite database

when I opened Expert I accidently ckicked "Toggle Between blah bla " Blue Table button

after that my tables produce error "The database disk image is malformed."

[seandisanti]

SQLite database

when I opened Expert I accidently ckicked "Toggle Between blah bla " Blue Table button

after that my tables produce error "The database disk image is malformed."

is there a "fix yadda yadd" button beside that one? sorry i just don't have the patience for this today i think... help me help you. lol

[tobject]

strange thing is I can access table with command tool sqlite3.exe

but SQLite Expert program shows an error "The database disk image is malformed."

[seandisanti]

strange thing is I can access table with command tool sqlite3.exe

but SQLite Expert program shows an error "The database disk image is malformed."

try toggling the blah bla back by pressing the button again.

[jchd]

SQLite database

when I opened Expert I accidently ckicked "Toggle Between blah bla " Blue Table button

after that my tables produce error "The database disk image is malformed."

Try asking Bogdan (Expert author), but at this point your best bet is restoring your last backup. Not having a backup is something I find hard to believe, given the ease of use of this backup UDF which can run transparently while the DB is operating.

There has been an intermediate rush release (3.7.0.1) to fix a bug where writing a DB alternatively with 3.6.23.1 and 3.7.0 could produce such a result.

So you should either stick to 3.6.23.1 or jump to 3.7.0.1 (or wait for 3.7.1 due later this month) if you see benefit using the new WAL mode.

Personally I'll wait until the dust settles around this WAL thing.

[tobject]

It's a freaking miracle! I made and identical copy from TABLEXX to TABLEXX_2

via sqlite3.exe command tool and now Expert shows data and both tables without any errors!

so what the heck was it?

Edited August 8, 2010 by tobject

[tobject]

Yikes! I deleted TABLEXX_2 and again got the same error!

[jchd]

Which "toggle button" did you hit?

Which SQLite version do you use?

Which Expert version do you use? Free or Pro?

Do you get the same error when checking your DB with the CLI?

Can't you then .dump your DB to SQL then reload it into a fresh new DB? What happens then?

If you can pindown the issue to a set of simple operations on the demo DB I'm sure Bogdan would love to know!

Edited August 8, 2010 by jchd

[tobject]

I save the data and moved it to a fresh copy of the database.

One table was lost but it wasn't very important so it's ok

I need to do regular backups - for sure!

[tobject]

Blue Table button near Filters

[jchd]

If you mean the "Toggle between grid and text" button, I can't believe that its action alone may corrupt a working DB. What that means in my eyes is that it revealed at this point that the DB was corrupt well before.

If you run your application for extended periods, try placing a separate timer (using a separate connection, remember) for backing it up every couple of hours. Tune the blocksize parameter so that the backup is guaranteed to finish well before the timer retriggers. Backing up with separate connection needs to restart with every write, but using one connection for distinct asynchronous operations is a sure failure/disaster, as you now understand. To keep safe from backup never-ending restart if your application writes at higher pace than backup can cope with, then make the time raise a flag which you test in your application to have the backup made there. Make it backup the whole thing at once in this case (use -1 for $blocksize) as there is no point saving it in small chunks. Don't forget to shut off writing asynchronous timers for the duration of the backup (wich runs roughly at file copy speed, so that's essentially as short as possible).

It's also a safe net to perform a periodic integrity check, which you can also launch prior to every backup or from a dedicated long-timed timer (using yet another connection!) and trigger blinking red alarms if ever the check fails.

Full-fledge corporate-class server DB engines have provision for running such features transparently by themselves, but since SQLite is a bare-bones "passive" library, you have the responsability to schedule and perform those actions by yourself when you decide they are needed, if ever. But of course you would hate it if your cellphone would refuse to place a call for half an hour, pretending that it's busy checking the GPS database.

EDIT: I feel need to add the following remark.

If you are using the new WAL mode, you shouldn't rely on a simple copy of the SQLite database file. The reason is that in WAL mode, the changes are first writen to the journal mode, and that across transactions (whatever thread/process/user issued them) and until the journal size limit is reached or a checkpoint is made. Hence the SQLite backup API is the safest way to backup a live DB without gambling about the risk of silently getting a corrupt copy.

Edited August 9, 2010 by jchd