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
I just released my ASP.NET Global Error Handler HttpModule that can be used to capture application level errors and send e-mail notifications to a specified individual. For more information and to download this item please click on the following link. Click here to visit the ASP.NET Global Error Handler Download Page
Posted by Mitchel on Sunday, August 19, 2007
Recently there have been numerous discussions on the DotNetNuke.com Forums regarding hosting providers and who one should go with and who they should switch to because they are unhappy with their current provider. During all of these discussions I have always recommended the company that I use for hosting 3Essentials. Since making this recommendation I have been receiving numerous e-mails regarding the process to actually migrate a live site over to 3Essentials so I thought I would write a short blog article that explains the basics of moving a website over to 3Essentials, in actuality these instructions SHOULD work for most providers, however ther might be some differences.
Read more...
Posted by Mitchel on Friday, July 27, 2007
Recently I have noticed an increased number of questions regarding the upgrade process from DNN 3.x to DNN 4.x and overall I do not think there is very much good documentation available on how to actually complete the upgrade. Therefore with this article I will walk you through the process of upgrading a 3.x site to 4.x, I will try to cover as many of the "gotchas" as possible, but please remember as with all of my other tutorials PLEASE use these at your own risk!
Read more...
Posted by Mitchel on Thursday, June 28, 2007
Reducing the delay time upon first requests to a DotNetNuke or other ASP.NET website is something that I see asked quite often. This delay is due to the ASP.NET Worker Process compling a website, this articles will discuss the solutions available to prevent this delay from occuring. I personally find that the simplest solution is the best; the even better part is that it is free! First of all before I talk about the different solutions available let me first explain the issue and why it happens.
Depending on your specific setup and hosting environment this initial load time can be quite lengthy. I have noticed initial load times of anywhere from 4-5 seconds to over 25 depending on the server configuration and load. What is actually happening is that your DNN site is being compiled after the ASP.NET worker process has restarted. The worker process can restart for many reasons, however the most troubling one is due to site traffic. By default IIS will shut down the ASP.NET worker process after 20 minutes of inactivity meaning that the next request will restart the worker process and cause the compilation to occur.
Solutions
Now there are many different solutions to this issue I have recently noticed 4 distinct common recommendations. The first recommendation is a very simple fix, however, for those of us in shared hosting environments we cannot perform the needed changes. If you have access to administer IIS you can change the recycling properties of the ASP.NET worker process for your specific application pool. I have heard of many users changing the value from 20 minutes to be 6-8 hours to ensure that the process does not end until extreme cases of inactivity.
The second method to resolve this issue is the one that I personally use for all of my websites DotnetNuke or ASP.NET. This method relies on using an external service to “request” a page of your site every __ minute. DotNetNuke even provides a .aspx page that you can use for this purpose to limit the bandwidth used by these “keep alive” processes; keepalive.aspx. http://www.host-tracker.com provides a free service to monitor your website the added benefit is that they will track your overall site uptime as well. I use them for this website and they are directed to http://www.mitchelsellers.com/keepalive.aspx for monitoring. This should do a good job to keep your site active as long as the monitoring location sends requests every 10-15 minutes.
The other two options are site isolated elements that I have not yet tested and these involve placing various pieces of code into your application to have it call itself just before the worker process is shutdown. This can be done via an HTTP Module or via the ASP.NET Website Heartbeat event monitoring. I personally have not used these methods as I do not want to modify the DNN core, or the core of any of my ASP.NET applications. However, if you search for these topics online you will find many examples.
Conclusion
I hope this has provided some helpful information regarding the delays experienced when requesting the first page for an ASP.NET website.
Posted by Mitchel on Wednesday, June 13, 2007
I found the following article to be very helpful when I was looking for a method to call a specific javascript function right after an AJAX request. blog.jeromeparadis.com/archive/2007/03/01/1501.aspx
For my readers that are using DotNetNuke to build AJAX enabled applications you must perform one additional task in your code-behind file to ensure that you have a script manager referenced for use on the front end of your application. To accomplish this you must simply place the below call in the page load event and ensure that it is called at least on the first load of any page that needs access to the script manager.
DotNetNuke.Framework.AJAX.RegisterScriptManager();
Posted by IowaComputerGurus on Sunday, April 22, 2007
Previous Page
1 of 3
Next Page