When SQL Server has to perform calculations on both sides of a comparison operator within a Where clause, then this criteria cannot be considered when evaluating the usage of indexes. SQL Server must try to use other criteria within the query to figure out which indexes to use, and if there are none, the query processor will scan all of the rows in the table, evaluating these expressions one row at a time, in order to determine which rows to process or return.

SQL Server is a very deep, robust software package, as are most enterprise class DBMS applications.  There are many areas of functionality that work very well and are self tuning.  However, with that much functionality at the disposal of the developer community, there are also many ways that features can be overused, misused, or abused.  That being stated, there isn’t enough time with a single article to cover every possible conceivable performance situation that could arise.  So, this article will attempt to focus on 3 of the most common SQL performance related issues that one will encounter in heavily loaded applications. 

The performance of an application can be influenced by many things.  Hardware constraints such as lack of memory or slow disk sub system can be just as detrimental as application inefficiency.    However, in many situations the first is caused by second.  An inefficient application can be cheaper and easier to fix in the long run, then creating server farms or buying huge, super-beefy equipment and paying lots of people to keep it up and running.  (Not to mention increasing the payment for the electric bill, insurance, network infrastructure, power supplies, etc.)

SQL Server Profiler is one of the performance tools that are available in the SQL Server 2008. But this tool has been mostly under utilized by the Database Administartors. The SQL Server Profiler does various functions like:

In our first article we discussed ASP.NET Ajax and provided an overview outlining the features and the supported methods within DotNetNuke. In this second article we will walk through the process of creating a very simple demonstration module that utilizes some of these new techniques.  Before you continue with the tutorial outlined in this article you will need to have an installation of DotNetNuke (4.5.0 or later) as well as the Starter Kit Visual Studio templates installed. Both of these items can be obtained from the DotNetNuke website (http://www.dotnetnuke.com). In addition to this you will need to download the ASP.NET AJAX framework and Control toolkit, these items are available for download from http://ajax.asp.net To create our demonstration module we be creating a “Dynamic Module” that will automatically be compiled by ASP.NET as part of the entire DNN solution. To accomplish this we will start by opening our DNN Solution in Visual Studio, then follow the below steps.