One item that many people find unusual about my DotNetNuke installation guides is my insistance on NOT using the Database.mdf, dynamically attached database file for the creation of a DotNetNuke database. In my tutorials I have quickly dismissed the topic by noting that "issues" come up when trying to use a dynamically attached database and I leave it at this. Well after seeing more questions on this topic recently in the DotNetNuke.com forums I wanted to take a moment to put my $0.02 out there as to WHY I don't like it. I will do this by discussing quickly what the differences are in the two approaches, then I'll discuss the "downfalls" of each.
Differences in Approach
Everyone is most likely familiar with the common process for creating a SQL Server databse, during the creation process two files are added the .mdf which stores the actual data and the .ldf which stoes the log. When the database is created the files are typically placed inside the "Program Files" folder, storing them with the rest of the SQL Server files, although this location can be changed by the Server Administrator.
The dynamic attachment method uses a pre-defined database.mdf file that is located in the App_Data folder of the DotNetNuke installation. When the system connects to the database server this file is attached to the server and operates like a database on the server would normally, however, all data is stored inside the DNN location.
Why I Think Its Bad
One of the most common arguments supporting Dynamically attached databases is that they "save time". Well That might be true for the first connection, however, in my experience the time spent troubleshooting later makes it a much longer process. The first thing to remember is that the database is attached and it has a name associated with it, DotNetNuke when working with DNN, if you go to install a second DotNetNuke installation on the same server with the dynamically attached file an error will appear noting that the database already exists. For beginners this can be a very upsetting experience.
However, the most problematic downfall of dynamically attached databases in my experience is that you must "Attach" the database before you can manipulate it in SQL Server Management Studio or SSMS Express. This is a very common stumbling block as individuals will know that the database exists, however, SSMS will not show the database at all, until it has ben successfully attached.
Overall
I feel that overall there are no compelling reasons that would direct a person to use a dynamically attached database rather than a standard SQL Server database especially when it comes to databases that need to be administered on a regular basis. If working in a test environment it might be helpful to have a dynamically attached database, but that is a limited use case, and for the most part DotNetNuke databases at one point in their life will need to be administered, backed up, restored, or moved. For these actions a standard database is a good way to go.
Please share any comments/feedback below.
Posted by Mitchel on Monday, November 24, 2008
Recently I have been working on creating a dynamic reporting engine for use within the DotNetNuke system, a method to allow for the execution of a stored procedure and the proper display of the results. This includes creating a list of parameters, including dynamically loaded lookup systems and more. Well the most complex item that I have had to condition for was how to deal with filter options that require the use of the SQL IN clause, there are many ways of doing this, but I have found a way that appears to work perfect for my needs, this will be explained in this posting.
Read more...
Posted by Mitchel on Friday, August 08, 2008
Recently I have answered a number of questions regarding an easy way to export datagrid contents to excel format. In this blog post I will share a static class that I have created called "ExportHelper" which I use quite often to generate quick Excel exports of datagrid data. I will outline the process and the code below. It should be noted that this solution is NOT a DotNetNuke specific solution, I use this for both DotNetNuke and standard ASP.NET solutions.
Read more...
Posted by Mitchel on Thursday, May 22, 2008
Recently when browsing the forums on DotNetNuke.com I have noticed more and more
questions regarding Script Injection vulnerability in the core and third-party modules.
I have often found that at times it is hard for non-developers to truly understand
the concept of script injection and what makes a site vulnerable. So in this
article I will take a bit of time to discuss both types of injection that users
of DotNetNuke should be aware of, how to test for them, and also how to prevent
the vulnerability when creating modules.
Read more...
Posted by Mitchel on Tuesday, May 20, 2008
Recently I have been asked by multiple people what rapid design tools I use, or
what types of code generation tools do I use. Many people are surprised when
I tell them that for the most part I don't use any rapid generation tools.
I do use a few home grown tools, such as my Info Class Generator, which is available
on this site. However, that is as far as I go with automated code generators.
However, one thing that I have started using more and more frequently are Code Snippets
within Visual Studio.
I have found that creating a few helpful Code Snippets has allowed me to quickly
and easily format my code, and build my needed structures in almost no time.
In this blog article I will share two of my most commonly used Code Snippets, if
there is a demand I will post future code snippets here as well.
Read more...
Posted by Mitchel on Sunday, March 02, 2008
Part of getting ready for OpenForce '07 involved looking into Visual Studio 2008 and Silverlight. As happens every time I browse new technology I got quickly sidetracked and sumbled upon a Microsoft document that outlines all of the new features with C# 3.0 which will be released with Visual Studio 2008 as part of the .NET 3.0 framework. This article will give you a quick overview of the first thing I found, and honestly one of my favorites overall "Automatically Implemented Properties"
Read more...
Posted by Mitchel on Thursday, September 20, 2007