My main Media Manager database of about 20,000 video clips got corrupted about a year ago. I'm not sure how it happened. I think I might have a slowly dying Intel Rapid Storage Technology RAID of 2 pretty old Samsung HDDs, as I've had some other weird small-time data corruption. Or it might have been down to the dodgy Google Drive client that was syncing all my data with the cloud back then. Anyway I started getting MM errors by simply opening some tags or their parents in the tag hierarchy on the left.

I thought I had fixed it back then by mucking about with it, deleting some stuff, re-adding stuff, relinking etc.. And since then I have made lots of changes and it has behaved itself.

However I didn't actually add or remove any clips. When I finally attempted to do that again a couple of days ago, it wasn't possible and I was getting crashes with error message containing this sort of stuff:

Sony.MediaSoftware.MediaMgr.DataAccess.DataAccessException: Converted ---> Sony.MediaSoftware.Kernel.Database.GenericSqlException: SQL Server detected a logical consistency-based I/O error: torn page (expected signature: 0x55555555; actual signature: 0x41555555). It occurred during a read of page (1:179) in database ID 6 at offset 0x00000000166000 in file 'D:\Media-Manager-libraries\Video.medialib'.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online. (class 24 number 824) ---> ...

Scary. I attempted to get it going again from within MM only but no go. Any attempt to add or remove clips resulted in that crash. And I also noticed that some clips had the same dive site tag on twice, but I could only delete one of them, and couldn't find a 2nd copy of the tag in the tags hierarchy.

I do have backups from just before the corruption happened. I could restore from those but I've changed so much info since then that I would hate to lose.

As MM runs on Microsoft SQL Server 2005 I thought I would attempt to install Microsoft SQL Server Management Studio Express to try and fix it, as discussed years ago, but unfortunately it won't install beyond Windows 7.

So I installed Microsoft SQL Server Management Studio (SSMS) version 17.3. The notes say "There is no explicit block for SQL Server 2000 or SQL Server 2005, but some features may not work properly.". Worth a try.

I started Vegas Pro 14 with Media Manager, opened my corrupt Video.medialib, made a backup of it called "Video backup.medialib" and opened that.

I ran SSMS and it prompted me to connect to the Media Manager server:

"ASUS-X99" is the name of my computer.

I clicked "Connect" and it successfully connected. In the Object Explorer on the left the server name appeared.

I clicked the [+] next to the "Databases" folder to open it, right clicked on "Video Backup" (my database), chose "Properties" > "Options", set "Compatibility level" to "SQL Server 2005 (90)", then clicked OK. I'm not sure if this compatibility stage was really necessary but it sounded good.

I clicked "New Query" from the toolbar, clicked in the field that appeared and typed this:

DBCC CHECKDB ("Video backup") WITH NO_INFOMSGS, ALL_ERRORMSGS

I then selected all that text to highlight it and clicked "Execute" from the toolbar.

That gave me these horrifying results in the Messages pane below:

Msg 8928, Level 16, State 1, Line 1
Object ID 29, index ID 1, partition ID 281474978611200, alloc unit ID 281474978611200 (type In-row data): Page (1:207) could not be processed.  See other errors for details.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 29, index ID 1, partition ID 281474978611200, alloc unit ID 281474978611200 (type In-row data), page (1:207). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 180488201 and -1.
Msg 8980, Level 16, State 1, Line 1
Table error: Object ID 29, index ID 1, partition ID 281474978611200, alloc unit ID 281474978611200 (type In-row data). Index node page (0:0), slot 0 refers to child page (1:207) and previous child (0:0), but they were not encountered.
CHECKDB found 0 allocation errors and 3 consistency errors in table 'sys.sysprivs' (object ID 29).
Msg 8928, Level 16, State 1, Line 1
Object ID 69575286, index ID 5, partition ID 72057594228637696, alloc unit ID 72057594232635392 (type In-row data): Page (1:179) could not be processed.  See other errors for details.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 69575286, index ID 5, partition ID 72057594228637696, alloc unit ID 72057594232635392 (type In-row data), page (1:179). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 180488201 and -1.
Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 69575286, index ID 5, partition ID 72057594228637696, alloc unit ID 72057594232635392 (type In-row data). Page (1:179) was not seen in the scan although its parent (1:6109) and previous (1:12457) refer to it. Check any previous errors.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 69575286, index ID 5, partition ID 72057594228637696, alloc unit ID 72057594232635392 (type In-row data). Page (1:5631) is missing a reference from previous page (1:179). Possible chain linkage problem.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 69575286, index ID 7, partition ID 72057594228768768, alloc unit ID 72057594232766464 (type In-row data). Page (1:259) is missing a reference from previous page (1:270). Possible chain linkage problem.
Msg 8928, Level 16, State 1, Line 1
Object ID 69575286, index ID 7, partition ID 72057594228768768, alloc unit ID 72057594232766464 (type In-row data): Page (1:270) could not be processed.  See other errors for details.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 69575286, index ID 7, partition ID 72057594228768768, alloc unit ID 72057594232766464 (type In-row data), page (1:270). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 180488201 and -1.
Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 69575286, index ID 7, partition ID 72057594228768768, alloc unit ID 72057594232766464 (type In-row data). Page (1:270) was not seen in the scan although its parent (1:4063) and previous (1:305) refer to it. Check any previous errors.
CHECKDB found 0 allocation errors and 8 consistency errors in table 'property' (object ID 69575286).
CHECKDB found 0 allocation errors and 11 consistency errors in database 'Video Backup'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Video Backup).

The actual repair that follows won't work without being in Single User mode, so I then typed the following in the Query pane at the top. It can be below the previous line, or overwrite it:

ALTER DATABASE "Video backup" SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Again, I selected all that text to highlight it and clicked "Execute" from the toolbar. It successfully completed very quickly.

I then typed the following in the Query pane and executed it:

DBCC CHECKDB ("Video backup", REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS

After a few seconds, lots of text appeared in the Messages pane. Below each red error message it informed me that "The error has been repaired".

I then typed the following in the Query pane and executed it (and it completed very quickly):

ALTER DATABASE "Video backup" SET MULTI_USER WITH ROLLBACK IMMEDIATE

I then exited SSMS. It prompted me to save some Query items and I didn't bother.

I then exited Vegas and restarted Vegas. I opened Media Manager and made sure I had the correct "Video Backup" database open.

I restarted SSMS and ran this again:

DBCC CHECKDB ("Video backup") WITH NO_INFOMSGS, ALL_ERRORMSGS

That gave me the all-clear. I exited SSMS, then restarted Vegas and MM again.

I was then able to start adding and removing clips from MM. Those unusual "dual" tags were still there, so I deleted those tags from the list on the left (after taking note of what clips they applied to), and removed, re-added and re-tagged the clips that had the dual tags applied to them.

A little later in my process of re-building things in MM I had something refuse to behave correctly and I did find that I had to re-run the whole repair process again (on the latest, already-repaired version). But since then it seems to have settled down. It looks like I've been fortunate in that I haven't obviously lost much data. Or I might have done and I just haven't found out yet; it's a big database 😱.

Some forums will tell you that REPAIR_ALLOW_DATA_LOSS is overkill and that you should be able to repair this stuff with less force. Perhaps a SQL Server guru could achieve that, but the database check's "repair_allow_data_loss is the minimum repair level for the errors found" reads pretty clearly to me, and more importantly I haven't got a clue what I'm doing.

Anyway I hope this might help someone in the future. In truth, that's most likely going to be me 😂, as I'm pretty much alone and naked on Cobweb Street since the product has no future and won't run on Windows 10 after version 1511. My hunt for a replacement continues, but there's very little out there that I wouldn't have to rob a bank to afford.

One more thing... If anyone actually is delving into this stuff, I took a tip from this page to see which tables within Media Manager actually have the stuff in that gets used. I didn't use his repair procedure as the latter part was way beyond me. But this shows which tables are most used after a very short amount of use: