It started some three weeks ago. One morning, the website of our university ran an error, basically saying that user marc could not log in to the sql server. It was some 2 years ago since I installed the portal and I did not remember all the details, but I figured I must have used my own name for the sql account and something was wrong at the side of my web host.

Before calling for assistance, I decided to do some checking myself. A check of web.config taught me that indeed the sql account was marc and I even found the password which I had not used since the initial installation. My webhost uses Helm as control program and in Helm, there is a database object where these parameters are set. To my surprise, There was no sql database assigned in Helm. For clarity, the name of the original database was dnnuke and I had sole access of the database. The dnn program was set-up in my wwwroot, so I was both host of the dnn installation and administrator over the CUP portal.

After some emailing and instant messaging, I got 2 things: (1) a new empty database called dnnuke-2009 attached to my Helm account, for which I could define up to three accounts but not marc since that account already exists and (2) access for marc to the dnnuke database restored.

With (2) my website functioned again and though I would have liked to change the account name to something more professional, I could live with the fact that this account name was now fixed forever. And anyway, I might have to move the database tables and views to dnnuke-2009 sooner or later. It would have to be sooner, rather than later, as dnn started warning me that there was a critical update I should install.

During two year that I ran dnn, the website had not been my highest priority. I am not Khmer. I speak some Khmer, I can read and write it, but not to the point where I could write the content for a Khmer website. Six months ago, the university sent a staff member from administration to follow a course at a Khmer organisation that promotes open source software. I would then teach him how to build, maintain and manage the portal. This staff member hardly speaks any English, but that is both a blessing and a curse. My plan is to build the website out into an educational instrument, providing open university classes and distant learning opportunities.

The task is hard in an environment where understanding of modern technologies is limited to some very basic tools that might have been at the top of the industry around the turn of the century, but that are clearly outdated, one decenium later. But this again is stuff for a next message (if I have readers for this). The training of my assistant is slow. It would maybe improve if I could localize dnn for Khmer, but as I understand now, this is not for tomorrow.

Anyway, there I was, with two databases and a critical update waiting. I know just enough of sql to write (quite fancy if needed) select statements and to do very basic user management. I used SQL Server Management Studio Express. Before starting the update, I made sure to make a backup.  The management studio made the backup to "E:\Microsoft SQL Server\MSSQL.1\MSSQL\Backup", which I then figured could be on my computer, since I had made a copy of my own SQL server (express) when I installed a triple boot sector system (XP, Vista and Win7 RC). It was not, as I later discovered.

After the backup, I copied the upgrade to my webroot. It was not the current version, but the one that came just before it. The upgrade failed and I had to restore dnn to its previous version.

Now comes the surprise. It seems I can make backups but I have no authority to restore them. The site was again in a big mess. My host said that I should make my backups with SQL Management Studio full version using the export function and restore using the dastabase publishing wizard. The publishing wizard is no problem, it is free downloadable, but the full version of the SQL Management Studio is part of Microsoft SQL Server (not Express) and harder to come by.

Anyway, the data in the dnnuke database was corrupted and the backup remained unattainable. I tried everything, in vain. When I restored the dnn files in my wwwroot, I could go through my website, but the menu system (I guess it is called Solpart?) did no longer function. However, I was able to open every page, the administrator->pages page was stored in my favorites and from there I could navigate to every other page. As you may have seen, the site is not yet that voluminous, so it took me one weekend to copy all HTML code to a text file, intall a clean version of dnn (now at 5.01.02) and reconstruct all pages and all modules, using the dnnuke-2009 database.

And this is why my upgrade was not an upgrade.

I remember in 2000, I was working for a EU programme in Cambodia and the project manager thought he made a backup of his files by copying files and pasting links to his backup media (a zip drive). Had I made the same mistake? Was I so stupid to think I made a backup where in fact I hadn't, only on a different level? Making mistakes can be advantageous if one learns from his mistakes, but here it is not clear who made the mistake or what the mistake was.

The backup strategy now works, the restore failed again, but now because the publishing wizard says that the tables cannot created because they already exist. So it seems the restore would work if I started out with a clean database. I do not feel confident enough to delete all my tables and views to test the restore procedure. I will test it out on de (now defunct) 'dnnuke' database, tonight or tomorrow.

Please feel free to comment on how stupid I have been.

And of course, if anyone has taken notice of the "bug" in my first message, let me know. It would feel good to hear that at dnn they take notice of these reports and that sooner or later (sooner please...) something will be done to restore the 4.09.?? functionality. Also, does anyone who uses dnn with east-asian languages has the same problem (or is it only Khmer that shows this behaviour?)

Regards, Marc