This bug just wiped out the PortalDesktopModules data for one of our 5.6.7 sites that has 23 child portals. I don't use the Premium Module function very often, but Murphy's Law demanded that I had to use it on July 27, 2012 -- while I was on vacation, without knowing that it was broken, and only now discovering that my client can't use the most basic of DNN functionality -- adding a module to a page.

It's unfortunate (well, that's quite an understatement, isn't it?) that DotNetNuke Corp. will not be fixing this issue, especially when it's clear from these Forums that it was a known issue LONG before the 5.x end of life date of July 20.

Now I have to waste my valuable time (and bill my client, which I'm sure they will NOT appreciate) to fix something that DNN Corp. should have fixed a long time ago.

If anyone has a Stored Procedure handy for repopulating data in the PortalDesktopModules table, I'd appreciate it.

Thanks, Mike. I think the backup recovery process will be the way to go. Luckily we have a pretty robust backup plan, with offsite storage of month-old tapes.

Until I can get the tapes, I need to restore functionality for our users. With about 80 modules installed, I wondered whether it would be possible to use a SQL statement to rebuild the table, allowing every module to be used by every portal. And then manually remove the ones that I don't want people to use...

But I'm just going to use the Host Extensions page and do it manually. What a pain in the ... neck.

And thanks for posting your edits to the stored procedure. At least this won't happen again.