One of my clients use a VB.NET/MS SQL Server application which I built for them. They accidentally deleted a widget from their database. The application keeps track of about 200 widgets per year. These widgets are complex things whose key variable information is held in 8 seprerate tables. This particular widget had 111 children and involved over 1900 seperate records across the 8 tables. The records are linked using sequential number primary keys. Restoring this record is not a trivial cut and paste job.
I had done something similar to this with a proper database before. Then I used mysqldump to export the data into a set of SQL INSERT statements. Next I cleaned up these leaving only the ones I wanted and then ran the SQL script which inserted the required records into the live database.
After a bit of looking around Microsoft SQL Server Database Publishing Wizard came to the rescue. It can basically take a snapshot of your database into an SQL script which you can then run against a different database.
I got it here
When installing “Microsoft SQL Server Database Publishing Wizard” It complained about some missing dependancies, but it also showed me where to get them.
Then I loaded up the backup database on my test system. Deleted all other widgets except the one I wanted. Then I checked the database to make sure the only records in the 8 tables were pertaining to the required widget. Then I ran Microsoft SQL Server Database Publishing Wizard to generate the SQL script. Then I edited the script and removed any extraneous lines leaving only the INSERT statements. It looked something like 1900 lines of this:
INSERT [dbo].[WidgetChildQtys] ([id], [widget_child], [qty]) VALUES (14007, 5308, 3000)
INSERT [dbo].[WidgetChildQtys] ([id], [widget_child], [qty]) VALUES (14008, 5308, 5000)
INSERT [dbo].[WidgetChildQtys] ([id], [widget_child], [qty]) VALUES (14009, 5308, 10000)
When restoring a bunch of records like this, because the database has changed since they were removed, there is no guarantee that they will simply import correctly. It will be fine provided none of the primary keys you are importing have been hijacked by any new records in the meantime. I waited until I could shut down the application. Then I did a test on a copy before I restored to, and reinstated the live database.