Software Development

Running MS SQL scripts from .Net

Fredrik Mörk — Sun, 02 Dec 2007 18:12:00 GMT

I was trying to have some C# code execute a database script to set up an MS SQL database, but the script was failing. Google helped me out (a bit lazy this sunday evening) by providing this blog post: How to run a SQL database installer from your .net application, by David Szabo. However, the script still failed me (much later in the script, but still). This time it was more obvious. David's solution to the problem was simply to split the string containing the script on the word "GO". In my case though, the script included the creation of a stored procedure containing a GOTO statement. Since I was splitting the string on the characters "GO", GOTO lost its verb, and the remaining part got to start a new element in my string array of commands to execute. So, I altered the solution slightly to include the carriage-return and line feed characters before and after the GO statement in the script:

        // Runs the given database script on the given connection. The script
        // is divided into commands by splitting the incoming script string
        // on the "GO" word, including the surrounding carriage-return and
        // newline characters, in order to avoid splitting on other occurrances
        // of the characters "GO"
        private static void RunScript(SqlConnection connection, string script)
        {
            string[] commands = script.Split(
                new string[] { "\r\nGO\r\n" },
                StringSplitOptions.RemoveEmptyEntries);

            for (int i = 0; i < commands.Length; i++)
            {
                SqlCommand command = new SqlCommand(commands[i], connection);
                command.ExecuteNonQuery();
                command.Dispose();
            }

        }

The script worked, and I was happy and smiling.

The importance of a consistent UI

Fredrik Mörk — Fri, 17 Mar 2006 14:39:00 GMT

Programmers are not generally known to be the best UI designers. Many programmers will willingly say that "GUI design is not really my cup of tea; I want to write code" or something like that. And that's fine. This means that when a typical programmer throw together some little application for their own use, the GUI of that application might not be perfect. And that's fine too. But when you start to charge prices in the neighbourhood of €1000, then you can't do that anymore.

The screenshot provided here comes from such a software, showing the lower-right corner of two dialog boxes (the upper dialog is displayed by the lower dialog). Notice how elegantly the "OK" and "Cancel" buttons traded places. I wonder how many users (apart from myself) that happened to hit the Cancel button, get a bit surprised, opening the dialog and re-making the selections and then realizing what happened. Also notice how it says "OK" with capital letters (as it should) in one dialog, and "Ok" with lower-case "k" in the other.

In this case it didn't do any big damage: I lost a few seconds of time in an operation that is not repeated very often. But the damage that it does make, is that it damages my confidence in the company releasing the software; if they have these kinds of flaws in the UI, what is there to be found in the code?

Future .Net Framework stuff

Fredrik Mörk — Wed, 14 Sep 2005 09:11:00 GMT

Microsoft has published some information about what we will see in future versions of the .Net Framework. One of the most interesting things in my opinion is the LINQ Project. It is an extension to the .Net Framework that will give developers some new language elements to create queries and such integrated in the native code. Instead of building a string containing an SQL statement, the query is constructed directly by code elements. Apparently it will work on any object that implements the IEnumerable interface, making it useful not only when working with databases.

You can read more about this on the LINQ Project web site.

Issues With Immutable Strings

Fredrik Mörk — Mon, 15 Aug 2005 13:55:00 GMT

The String class in .NET is immutable. That means that once an instance of the String class has been created, its content cannot change. Look at the following code:

Dim vTheString As String = "Some random text"
vTheString = "Some other text"

What happens here is that a string instance is created with the value "Some random text", and it is referenced by the variable vTheString. Then a new string instance is created with the value "Some other text", and the variable vTheString will be altered to reference that new string instance instead. This is usually not an issue, but there are things to be aware of here. An example:

Module AppMain
    Private Class JustForTesting
        Public Value As String
    End Class

    Sub Main()
        Dim vTestObject As New JustForTesting
        vTestObject.Value = "This is my test."
        AlterTestObject(vTestObject)
        Console.Write(vTestObject.Value)
    End Sub

    Private Sub AlterTestObject(ByVal testObject As JustForTesting)
        With testObject.Value
            If .StartsWith("This") Then
                testObject.Value = "Which" & .Substring(4)
            End If
            If .EndsWith(".") Then
                testObject.Value = .Substring(0, .Length - 1) & "?"
            End If
        End With
    End Sub
End Module

This code will create a JustForTesting instance, assign the string "This is my test." to the Value field, call a method that apparently replaces the word "This" with the word "Which" and also replaces the dot in the end with a questionmark. It then prints the content of the Value field to the console output. And what it prints is:

This is my test?

Why is that? Where did the replacement of "This" to "Which" go? This is where immutable comes into the picture. The AlterTestObject method starts off by setting up a With-block which is often considered good practice when you are about to access an object several times, in order to improve performance a little bit. When the with block is set up, it will reference the string instance of the Value field of the JustForTesting object that is passed to the method. The code then checks if that string instance starts with "This". It does, so the code will assign a new string, starting with "Which", followed by the string after character 4 in the string instance referenced by the with block (resulting in "Which is my test.").

Since the content of a string instance cannot change, a new string instance will be created and the JustForTesting object's Value field will be changed to reference that new instance. This is where it goes "wrong". The Value field is now referencing a new string instance, so the with-block and the Value field are now pointing at two different strings.

Next the code will check if the string referenced by the with-block (which is no longer the same string instance as the Value field) ends with a dot. It does, so the code will assign a new string, starting with the string referenced by the with block up to the second last character, followed by a questionmark (resulting in "This is my test?").

Conclusion: do not set up with-blocks which reference immutable objects, if the code within the block might alter their content.

Enum, 0 and Nothing

Fredrik Mörk — Tue, 26 Jul 2005 10:26:00 GMT

One feature that I like a lot in the .NET framework is Enumerations. They can be used for all sorts of things; indicating a variation of an object, encapsulating a static list of values that a certain field or property can hold and more. Since all Enumerations are based on Integer-related datatypes (such as Byte, Long or Integer), so the individual enumeration values will in the end be an integral numeric value. So far, so god. Let's make an enumeration (I'll use VB.NET syntax):

Private Enum UIState
    Resting
    Working
End Enum

This is a very simple enumeration for indicating the current state of the GUI. Either it's Resting, waiting for user input, or it's working, so the user will wait. Actually, this enumeration is so simple that it could have been replaced by a Boolean, but for the sake of the discussion, I'll disregard from that.

Since I have not declared a type for the enumeration, it will be Integer, and as I have not assigned values to the enumeration members, they will automatically get a sequence of values starting at 0 (0, 1, 2, ...). Great! Seems simple enough. Now, I want to write a function which will set the correct properties of my controls depending on the current state. If the method is called with no state passed, I want it to default to Working:

Private Sub SetControlState(state As UIState)
    Dim vLocalState As UIState
    If state = Nothing Then
        vLocalState = UIState.Working
    Else
        vLocalState = state
    End If
    ' Here comes the code to set state of controls...
    ' ...
End Function

Now comes the funny part. If I make the call SetControlState(Nothing), I will assume that it uses the UIState.Working value to carry out its operations. It won't. Instead it will happily use UIState.Resting. Why is that? The answer is; because the values of UIState are of a value type. In the .NET world of integral values, 0 and Nothing (or null in C#) are the same. So the following two lines of code will give the same result:

    If state = UIState.Resting Then
        ...
    If state = Nothing Then
       ...

Since UIState.Resting = 0, and Nothing = 0, they are the same. How do we get around this? It's easy: always assign explicit values to your enumeration members, and don't use 0:

Private Enum UIState
    Resting = 1
    Working = 2
End Enum

Now the SetControlState method will correctly default to Working if Nothing is passed as parameter.

There is one thing to keep in mind if you use enumerations like this, though. If you make a user control (or any other type that will be used in a design time environment), and that type has a public property that is of an enumeration type that does not have a member with the value of 0, you will get some error messages from the development environment. By default it will try to assign 0 to the property, which is an invalid value. There are two ways around this; either make sure to define a valid default value for that property (using the DefaultValue attribute) or create a member called "NotSet" (or "None" or something similar) and give it the value 0.

To Hungarian or Not to Hungarian

Fredrik Mörk — Thu, 12 May 2005 08:36:00 GMT

When I started out programming, even though I was never a C programmer, it was more or less mandatory to use Hungarian Notation when naming variables. With the introduction of .NET the official recommendation was not to use it, since it didn't really add any value (which I very much agree with). But it seems as if the Hungarian that has been used by many programmers (myself included) is based on a simple misinterpretation of the original notation, which is actually very useful, strong type system or not.

There is an interesting article on the subject on joelonsoftware.com.