Tuesday, April 19, 2011

MARS - Multiple Active Result Sets support in SQL Server 2005 and above

SQL Server 2005 onwards supports MARS - Multiple Active Result Sets. MARS enables you to reuse an existing connection to perform operations on SQL Server. This makes MARS a viable alternative to server-side cursors with significant performance boosts. As powerful that may seem it has it's drawbacks so care needs to be taken when using it.


Here's an example from msdn:

SqlCommand cmd = conn.CreateCommand();
SqlCommand cmd2 = conn.CreateCommand();
cmd.CommandText = @"select operation_id, operation_code, product_id, quantity 
      from dbo.operations where processed=0";
cmd2.CommandText = @"update dbo.operations set processed=1 
      where operation_id=@operation_id";
SqlParameter opid=cmd2.Parameters.Add("@operation_id", SqlDbType.Int);
reader=cmd.ExecuteReader();
while (reader.Read())
{
   ProcessOperation();
   opid.Value=reader.GetInt32(0); // operation_id
   //notice how we are trying to execute an update query on the second command
   //this is going to fail miserably because
   //we did not set MutipleActiveResultSets=Yes 
   //on the connectionstring
   cmd2.ExecuteNonQuery();
}

By default MARS is not enabled. So reusing the same connection as the example above will throw an exception of type :

InvalidOperationException, There is already an open DataReader associated with this Connection which must be closed first.

Say hello to MARS :

Enabling usage of MARS is as simple as setting MultipleActiveResultSets=Yes on your connectionString, eg:

<connectionStrings>
    <clear />
      <add name="TyppsDB" 
         connectionString="Data Source=typps-pc;Initial Catalog=TyppsDB;
                 Integrated Security=True;MultipleActiveResultSets=Yes" />
 </connectionStrings>

you can now issue multiple commands on the same connectionstring which can result in a performance boost since opening and closing a connection can be expensive.

When retrieving recordsets, the client has to eager load, meaning consume the resultsets immediately as oppossed to executing the command and not reading the data. Not doing so will cause the server-side buffer(Where sql server is hosted) to hold on to the data in memory and tie up resources, locks, threads etc something you want to avoid.

Instead you want the data to stream to the client as fast as possible as the server returns the resultset without the server holding a large recordset in memory and tying up resources. This is not specific to MARS by the way, but when used correctly with eager loading meaning you consume the data as the command is executed  you can benefit from a significant performance boost as you have the ability to execute more commands and retrieve data seamlessly without the overhead of closing and reopening a connection to Sql Server.

myReader = myCommand.ExecuteReader(); while(myReader.Read())
{
 //consume immediately now, don't wait.
}

Any command that is a SELECT, FETCH, READTEXT, RECEIVE, BULK INSERT (or bcp interface) or Asynchronous cursor population can take full advantage of MARS.

What this means is that with MARS enabled, each of these commands listed above are defined in terms of interleaved executions, allowing them to be processed atomically within the same connection but with the ability to interleave, this means they can resume execution from the points where they were suspended if at all suspended.

For instance, INSERT and UPDATE cannot take advantage of MARS. Now, consider a long running INSERT or UPDATE operation followed by a SELECT statement, all executing within the same connection. Such an operation will suspend the SELECT command until the UPDATE or INSERT has completed and then resume the SELECT operation.

Consider reversing the above example where you had a SELECT followed by an UPDATE or INSERT operation within the same connection. Even in this case, if the UPDATE or INSERT command are issued while the SELECT is executing, then the SELECT command will interleave and as such become suspended until the INSERT or UPDATE complete and only after completion of the UPDATE or INSERT operation, will it resume execution.

This is because the SELECT command can take advantage of MARS and has the ability to resume from the point where it was suspended making it an interleaved execution.

Lastly, note that there are some intricacies when using transactions with MARS. You will need to workaround using recommendations provided eg: by using batch-scoped transactions.

References :
http://msdn.microsoft.com/en-us/library/ms345109(v=sql.90).aspx
http://msdn.microsoft.com/en-us/library/ms174377.aspx

Monday, April 18, 2011

.NET exceptions, error handling for the exceptional case

The tip of the day consists of, in making sure to use a try/catch block to trap individual exception types such as SqlException which is specific whereas Exception being more general.

For instance, imagine you are connecting to a database, it's quite common to experience a connection failure that you might not expect. So it makes sense to try to handle any unexpected connection failures.

First, try and discover the SqlConnection members class on msdn and drill down to the SqlConnection.Open method, there's a section including the exceptions that the open method may throw and we find two :

InvalidOperationException and SqlException with the specifics on what the conditions are when these exceptions are thrown.

Similarly, we can write code likewise :

try
{

 //connect to db and do something useful
}
catch(InvalidOperationException invalidException)
{
 // specific exception
 // usually occurs when trying to open a conenction
}
catch (SqlException sqlexception)
{
 // specific exception
 // will occur when opening a connection
}
catch (Exception exception)
{
   // lastly the general exceptional case will kick in
   // could be anything that the first two exceptional cases didn't catch.
}

Note how Exception ( the mother of all exceptions) is handled last and instead we branch out by starting with more specific exceptions, InvalidOperationException and SqlException. This allows us to catch more specific exceptions and then move on to the more general exceptions. This is a good practice.

Lastly, when logging your exceptions, use the default implementation of ToString of the exception thrown to obtain the name of the class that threw the current exception, the message, the result of calling ToString on the inner exception, and the result of calling Environment.StackTrace with line number etc.

Final notes:
If an exception can be handled programmatically without resorting to try/catch then investigate that route first. Handle the exceptions that are relevant to your code, throw back everything else. Read Best Practices for Handling Exceptions

References :
http://msdn.microsoft.com/en-us/library/seyhszts.aspx
http://msdn.microsoft.com/en-us/library/system.exception.tostring.aspx
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection_methods(v=VS.71).aspx
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.open(v=VS.71).aspx

kick it on DotNetKicks.com
Shout it

Friday, April 15, 2011

Silverlight or Html5 - from A .NET developer perspective.

Html5 vs Silverlight for the .NET developer :

If you are already invested in .NET, then you have been honing a particular set of skills for the past decade. This puts you at a position where it is difficult to favor Html5 simply because you lose some agility and sometimes this may make all the difference.

Since MIX11, there is much debate with regard to Html5 vs silverlight. And developers continue to ask, what should I use. When I try to make a decision on the technology to use and power my applications the following facts helps me consolidate my ideas and beliefs further and this is also my current state of mind.

  • Silverlight is cross browser / platform

Note: This is great news if we are comparing silverlight to wpf but when compared to html5, we can agree on one thing. Html5 will be available on many more devices so it's not actually a pro for silverlight however, it's good to note that silverlight runs on those devices where it counts :

All major browsers on both the mac and windows are supported. *nix support through Novell mono moonlight, which currently lags a bit behind but don't let this be a show stopper for you. You can easily develop a secondary slim version that works for moonlight which currently fully supports version 2.0 of silverlight and one that supports 3.0 is almost complete.

Depending on the features your using, you might even be able to provide support for your application in it's full glory or perhaps with a minor workarounds if this audience is very important to you. Finally you also get to target the mobile platform wp7(Currently html5 support is lagging on wp7).

  • Strongly typed languages support (c#, vb.net). Unlike losely typed languages, you will benefit greatly from compile time error checking, and many language specific features.
  • Easy deployment --your compiled silverlight assembly includes the compiled code and xaml files for all your pages in your application. These files are embedded as resources and are compressed. While this is the default, it's also very flexible, meaning you can split your code in modules that can be dynamically downloaded by your silverlight application upon request. Tip: Prism is a great library if you want to benefit from modularity among other things in your silverlight apps.
  • First class IDE support. Not only are you benefiting from superb IDE support for both designing your applications in expression blend while doing the development in visual studio, but your way of working changes very little if you are already a developer in the microsoft space. Note that we will soon see some pretty good IDE support for Html5 as well, so this particular con for html5 won't hold true for very long.
  • Reuse existing known code patterns. Patterns and practices have been gathered over the years and are a way for us to reuse "experience" in our development. Some are our own, some are industry known patterns and practices. On the other hand, Javascript too has been around for a very long time and they too have adopted their own set of patterns and practices, but clearly as a .NET developer, with silverlight, you don't have to relearn anything. I do heavy development in both c# and javascript, so this point is pretty moot for me, however, it's an important decision maker when chosing the right technology.
  • Reusing existing code --You already have existing code written for the .net framework, be it code that simply executes on the server or perhaps a WPF desktop application. Porting this code to run on the client instead in silverlight is much easier than rewriting it from scratch in javascript.
  • As a web developer, you write client-side code for Silverlight in the same language that you use for server-side code (such as C# and VB), similarly you will be able to leverage the same objects you use on the server, so : generics, LINQ, Lambda, collections and many more even though only a subset of the .NET framework classes.
  • IE8, 7 and 6 support is important to you because you still have a lot of clients on these browsers. This is a given in silverlight, yet these browsers currently do not support the html5 featureset. Using another third party plugin such as google frame to target content to this user group ( also currently constituting the majority) is out of the question. Why should the largest portion of your userbase be served in downlevel?
  • Install and upgrade --fully managed install and upgrade mechanism in place for Silverlight. This means as new versions of silverlight are made available, we can start using them in our applications right away and based on the runtime version of silverlight your applications are built against, that version will be used or the user will prompted to download and install it. This is fully managed by Microsoft and you do nothing in this department other than some minimal configurations such as MinRuntimeVersion and so forth.
Counter this with Html5, where features that constitute Html5 are supported at the discretion of the browser vendor. This means each browser vendor will pick up the feature they think is useful or important and will implement it. This makes it quite easy to find a feature that works in one browser but doesn't work in another or simply a feature that works in the latest versions of the browser while your left working around to compensate for the feature loss in older versions.

In fact not too long ago whatwg has officially moved to a non-versioned model where Html5 is simply known as Html. This move by whatwg makes sense to me also because no browser currently supports the entire featureset of Html5 and therefore the name is misleading. Infact no browser ever supported html4 completely. Silverlight, being a plugin does not suffer from this lack of feature uniformity across browsers/devices.

Final notes : 
One thing is sure, Html5 has been a hot topic for a while now and with the release of ie9 it has gotten even hotter. This is a fresh area with room for plenty of innovation and new business opportunities to tap into. Like all new things, there's a gold rush. Everybody is pushing out web applications that uses shiny new Html5 features, because that is the current trend and there's lots of room for investment. This is a large market segment with a wider audience.

As a .NET developer, if you are selling development tools, you are no longer confined to Microsoft developers, instead suddenly the web is your oyster. Lastly, it makes the headlines to invest in Html5 at this early stage, which can quickly translate to free marketing for you. That's someting to consider as well.

So, in the end, which one is the better? Today I'm confident about my silverlight investment because it made sense for my application and it's needs. However on a different project, I may sing a different tune all together. Sadly, there is no better choice. You know your application, only you know what it needs.

For instance I developed Abmho based on need. I couldn't find a proper syntax highlighter on the web that simply worked, that wasn't riddled with adverts and one that didn't require me to make a request to the server everytime. Soon this became irritating and so I decided to make one myself.

It was important that my syntax highlighter executed in the browser as an application and was fast and responsive. I also wanted to complete development fast and I have a .NET background. I also already had a syntax highlighter library in c#. Rewriting this library in javascript would have simply taken forever. It was certainly not worth the effort.

This move allows me to ship a wpf version (currently in the works) that requires subtle minimal changes to get working as a full fledged desktop application that I will be making available soon since Silverlight is a subset of Wpf. All this wouldn't be possible if I had gone the Html5 route.

Setting up a ConnectionStrings in .NET

ConnectionStringBuilder :

Tip for today is the ConnectionStringBuilder class. This is quite an unknown class but can result very useful in building your connectionstring. Normally, you'd take a connection string and pass it directly to your connection objects such as SqlConnection or DbConnection classes directly.

Quick example from msdn :

private static void CreateCommand(string queryString,
    string connectionString)
{
    using (SqlConnection connection = new SqlConnection(
               connectionString))
    {
        SqlCommand command = new SqlCommand(queryString, connection);
        command.Connection.Open();
        command.ExecuteNonQuery();
    }
}


As you can note from this classical example above, the connectionstring is passed directly to the SqlConnection object's constructor. While this is fine, any error in the connection and it's quite easy to make a mistake, won't be known until the connection is opened.

Further more, if you want to pass some additional values, or modify existing values in the connectionstring it can be time consuming and again error prone and more effort than you want to invest.

Say hello to the ConnectionStringBuilder. What this class does for you is that it facilitates parsing a connection string and also provides named properties you can simply set in code or whose values you want retrieved. A classic code example from msdn itself :

using System.Data;
using System.Data.SqlClient;

class Program
{
    static void Main()
    {
        // Create a new SqlConnectionStringBuilder and
        // initialize it with a few name/value pairs.
        SqlConnectionStringBuilder builder =
            new SqlConnectionStringBuilder(GetConnectionString());

        // The input connection string used the 
        // Server key, but the new connection string uses
        // the well-known Data Source key instead.
        Console.WriteLine(builder.ConnectionString);

        // Pass the SqlConnectionStringBuilder an existing 
        // connection string, and you can retrieve and
        // modify any of the elements.
        builder.ConnectionString = "server=(local);user id=ab;" +
            "password= a!Pass113;initial catalog=AdventureWorks";

        // Now that the connection string has been parsed,
        // you can work with individual items.
        Console.WriteLine(builder.Password);
        builder.Password = "new@1Password";
        builder.AsynchronousProcessing = true;

        // You can refer to connection keys using strings, 
        // as well. When you use this technique (the default
        // Item property in Visual Basic, or the indexer in C#),
        // you can specify any synonym for the connection string key
        // name.
        builder["Server"] = ".";
        builder["Connect Timeout"] = 1000;
        builder["Trusted_Connection"] = true;
        Console.WriteLine(builder.ConnectionString);

        Console.WriteLine("Press Enter to finish.");
        Console.ReadLine();
    }

    private static string GetConnectionString()
    {
        // To avoid storing the connection string in your code,
        // you can retrieve it from a configuration file. 
        return "Server=(local);Integrated Security=SSPI;" +
            "Initial Catalog=AdventureWorks";
    }
}



Note: the same applies for the generic non SqlClient class DbConnection and you'd use the apposite DbConnectionStringBuilder class.

Lastly, retrieving the connectionString itself can be facilitated by using Server explorer, after having made the connection to the database visually in VS.NET you need to select your database in solution explorer and right click - Properties. From the property grid you can see the connectionstring VS.NET is using. That is the connectionstring you want.

Alternatively you can use create a DataLink and copy the autogenerated connectionstring created by the DataLink. Follow the url in the references section below.

Reference material :
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnectionstringbuilder.aspx
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.aspx
http://msdn.microsoft.com/en-us/library/ms718102(v=vs.85).aspx ( DataLink )
http://msdn.microsoft.com/en-us/library/33wwc2yw(v=VS.80).aspx (Server Explorer)

Sunday, April 10, 2011

Typps 3.1 released

A new 3.1 stable release is available for download.

Tuesday, March 29, 2011

Typps 3.0 released

We haven't been blogging much. We'll try to improve in that too. In the mean time know that 
3.0 is now released. This version fixes many problems among which issues in IE9.


Friday, November 12, 2010

Typps Version 2.7 released

We have a new release that fixes an important bug in when running the editor in a website that targets .NET 4.0 and Ajax control Toolkit. This release does not break any features so it should be a fairly easy upgrade.

Currently we are restructuring code in preparation for new features. So unless there is a major bug to fix, we will be skipping a few iterations.

One of the things we don't currently do is check in our code on codeplex. Instead we make releases and put out packages in the download section. Hopefully from the next release onwards we will start doing that too.