Owkai, I admit the title is rather misleading, but it all will come clear to you when you read this post.
First the situation:
A customer of ours had a database corruption problem. This problem was pure SQL Server 2005 based, so at first it wasn't a MOSS 2007 problem. A colleague of mine (SQL Server DBA) went overthere to investigate the problem. Seemed that only some databases were affected by the problem.
The affected databases couldn't be backed up though. Luckily, most of the database could be restored to their last backup, since they were mostly "infrastructure databases" (like the configuration of vmware).
But, the content database of their MOSS 2007 installation couldn't, because people kept on working on it after the corruption. This causing some bizare phenomenons, some functionality worked, other didn't.
So then I got into play, since MOSS 2007 is primarily my toy. 
The solution:
Well, it got fixed quite easily, at least way more that I would ever dream of...
I backed up the Site Collection, using stsadm, to restore it again into a new clean database. That did the trick.
So, the well known command:
stsadm -o backup -url [URL] -filename [filename] -overwrite
to backup the Site Collection to disk and
stsadm -o restore -url [URL] -filename [filename] -overwrite
to restore it again.
Between those two commands, I just removed the content database from MOSS (Central Administration > Application Management > Content databases), and created a new one.
The restored site contained all the data and all the lost functionality had been fixed.
Talking about a quick and easy solution to what could have been a fucking big problem.
Happy customer, happy systems engineer.
NOTE: It has to be said, I was lucky only 1 Site Collection was in that database, otherwise I had to run the commands for every Site Collection in that database.
Happy again,
Tom