James Wiseman

Programmers like new toys that they can play with, be it a second monitor, a new IDE, or a new programming language. They also like to feel that they are learning new things and not getting assigned to the technological scrap-heap and so will inherently favour (for example) C#3 above VB6 even when the final solution might be suboptimal.

I found myself drifting into this mindset recently when prototyping a design for component to fit in with an existing framework of COM components.

The component needed to call out to SQL Server 2005 to start an Agent Job. My first instinct was that I had to interface with SQL 2005 Native Client components through the .NET libraries. I envisaged something something like this:

//...get the connectionString somehow...
string connectionString = "Data Source=SOMESERVER;Initial Catalog=SomeDatabase;Integrated Security=SSPI;Provider=SQLNCLI.1;";
OleDbConnection oleDbConnection = new OleDbConnection(connectionString);
ServerConnection serverConnection = new ServerConnection(oleDbConnection.DataSource);
Server oSqlServer = new Server(serverConnection);

JobServer oAgent = oSqlServer.JobServer;
Job oJob = oAgent.Jobs["Test"];
JobHistoryFilter oFilter = new JobHistoryFilter();
oFilter.JobName = "Test";
oJob.Start();

…or something similar therein.

The component would have to expose a COM Interface and be registered using REGASM, which would requrie manual intervension in the shipping process.

In addition to this, I would have neededed to organise for the SQL 2005 Client tools installed on four servers and undertake regression testing of the applications on these servers to inspire confidence that this hadn’t broken anything.

To be frank, it all seemed a little onerous and overcomplicated. Apart from simply wanting to use C#, the reason for this doing this was based on an assumption that I needed the .NET library code to hook into SQL Server and that there was no other way. Really? Have you ever heard such nonsense?

Without realising, I’d very nearly falling into the Second System Effect trap (of sorts). All I really had to do was make a call out to the SQL Server sp_start_job to achieve the same effect, and all I needed was trusty old MDAC 2.8. This meant I could write it in VB6 to fit in with existing framework components with none of the impact or complication inherent with the C#-developed component.

So, I set about writing a little test application as proof of concept. It looked something like this:

Private Sub Command1_Click()
    Dim connection As New ADODB.Connection
    Dim connectionString As String

    connectionString = "Data Source=SOMESERVER;Initial Catalog=SomeDatabase;Integrated Security=SSPI;Provider=SQLOLEDB.1;"

    Call connection.Open(connectionString)

    connection.Execute ("EXEC msdb.dbo.sp_start_job @job_name=N'Test'")

    MsgBox ("Success")
End Sub

But I really wanted to use C#! However,  in this instance it just wasn’t feasible.

So, in conclusion, don’t get blinded by shiny new toys or by a desire to improve oneself, don’t simply dive into the first solution that you come across, and remember, complication is ruination!

Most C# (and C, C++, Java and JavaScript developers for that matter) will be aware of the default keyword and its usage in the switch statement:

switch (options)
{
    case 1:
        {
            //do something
            break;
        }
    default:
        {
            //do something
            break;
        }
}

But it also has an additional use in C# in conjunction with Generics and types. Each type in C# has a default value. Value Types have a default value of zero (false for boolean) and reference types have a default type of null We can try a simple example:

int i = default(int); //i is initialised to zero

And then try it in conjunction with Generics:

class DefaultTest<T>

{
    public DefaultTest()
    {
        System.Console.WriteLine("Default for '" + typeof(T) + "' is " + default(T));
    }
}

class Program 
{
    static void Main(string[] args)
    { 
        DefaultTest<bool> b = new DefaultTest<bool>();      //outputs 'false'
        DefaultTest<int> i = new DefaultTest<int>();        //outputs '0'
        DefaultTest<string> s = new DefaultTest<string>();  //outputs nothing
        DefaultTest<String> S = new DefaultTest<String>();  //outputs nothing
        DefaultTest<double> d = new DefaultTest<double>();  //outputs 0
    }
}

You can read some more on these in this article: http://en.csharp-online.net/Understanding_Generics—The_default_Keyword_in_Generic_Code

Here’s an idea of something to try when you’re trying to learn about C# and the .NET framework classes.

When using a type, why not include its namespace in your code as as well. For example:

//without namespace
OleDbConnection oleDbConnection = new OleDbConnection(connectionString);

//with namespace
System.Data.OleDb.OleDbConnection oleDbConnection = new System.Data.OleDb.OleDbConnection(connectionString);

I’m not necessarily advocating this for use when writing production or live apps (it is a bit wordy, but i’m undecided about that at the moment), however when you’re hacking about and learning new stuff, it may be advantageous for your learning experience if you include the full namespace declaration; hopefully this will help you remember the association between libraries, namespaces and classes.

Just a thought. Take it or leave it…