If you’ve ever needed to send a backup of your DotNetNuke database to a developer for testing, you likely trust the developer enough to do so without scrubbing your data, but just to be safe it is probably best that you do take the time to scrub.
Before you do anything with the SQL below, make sure you have a backup of your website! I would recommend you do the following.
- Backup your existing production database
- Restore a backup of your production database as a NEW database
- Run the scripts below on the NEW database
- Shrink the NEW database
- Backup the NEW database
Below I’ve included two SQL scripts that will help you with that data scrubbing, at least in respect to User emails and passwords.
This script updates the aspnet_membership table to set the password for ALL USERS to “dnnpassword” and the format and salt values. It also sets email addresses to a generic email.
This script updates the DotNetNuke users table to remove the email address from your users (assuming they aren’t using their email address as their username).
Another problem you may run into is the size of your database, if you have a lot of content you might want to scrub the Search tables and then shrink the database. Check out my old blog post for the SearchItem t-sql. Depending on the size of your database the search clearing might take a while, it will also likely INCREASE the size of your database due to the number of transactions.
Shrink your database after running the scripts. Backup the shrunken database.
I’m sure there are probably other tables you can and should scrub, I’ll add those to this post as I come up with them!
This is the fifth post in a series of blog posts about converting from CommunityServer to DotNetNuke.
A brief background: I had a number of websites running on CommunityServer 2.1, I decided it was finally time to ditch CommunityServer due to the change in their licensing model and pricing that made it not good for the small guy. This series of blog posts is about how to convert your CommunityServer based sites to DotNetNuke.
Previous Posts:
Part 1: An Introduction
Part 2: DotNetNuke Installation
Part 3: Converting users from CommunityServer to DotNetNuke
Part 4: Getting the conversion tables ready for CS to DNN
Part 5: Moving Forum threads from CommunityServer to DotNetNuke
Part 6, Community Server to DotNetNuke Moving Forum replies and attachments
Part 7: CommunityServer to DotNetNuke handling URLs
This is Part 5, bringing over Forum Threads
If you haven’t read the previous posts I would recommend that! This blog talks about CsToDNN_2.sql, and assumes you have already replaced the various strings discussed in Part 3. The CsToDNN_2.sql script is used to pull over the Forum threads, replies are pulled over in the CsToDNN_3.sql script (future blog post)
The script starts out by getting the number of threads we’re going to need to loop through. Next we truncate a table called cs_forums_topics, this table is used for keeping track of the CommunityServer PostId and the DotNetNuke TopicId. This will be important during the importing process, and also after we’ve got our DotNetNuke site running so that we can properly map the old CommunityServer URLs to DotNetNuke.
After truncating the table we go through and PostIDs from CommunityServer, at this point we’re just populating that table, nothing more. Later in the script, and the CsToDNN_3 script we will be updating the cs_forums_topics table with the matching id.
After populating that table the script then primes the first post to import, setting up a number of variables that we’re going to use when populating the DNN Forum module. At this point the script does a while loop, initially inserting the primed forum post into DNN using the Forum_Post_Add_Conversion script that we created in the CsToDNN_1.sql script. After adding the forum thread the script updates the cs_forums_topics table, and then the loop primes the next thread to add before starting the loop over. This while loop will repeat until all of the threads are imported.
With my forum which had around 40k threads, this script ran fairly quickly, 5-10 minutes if I recall correctly (it’s been a few months).
Side note: while reviewing the scripts for this post I noticed that there were a few things that needed changing, so I checked in new changes. After I’m done with this series I will do a new release of the CsToDNN package, until then check out the Source page.