Question

I’ve inherited a piece of code at work and I’ve just noticed a fairly trivial but bizarre little quirk with it. So maybe someone can save me setting up clean .NET 2.0 Environment to test it out.

There is a SQL2K5 table containing a column called IsEnabled BIT NOT NULL

There is a sproc selecting from that table

There is a piece of C# code which, using a SQL Reader calls that SPROC, loops through the result rows, and writes some of that info to a log file as well as doing other things.

using (SqlDataReader reader = DAL.SqlHelper.ExecuteReader(connStr, "usp_MySproc"))
{
    while (reader.Read())
    {
         //code to do stuff...

         string s = reader["IsEnabled "].ToString(); //exactly like this...

         //code to concatenate `s` with other values
         //log it all to file
    }
}

The odd thing is, in some older log files, that value is written out as a 1 or a 0 whereas in newer logfiles it’s written out as a true or a false

So one of the following things has happened. It was caused by:

1. Someone changing the code
2. Someone changing the datatype in the table from int -> bit
3. Someone changing the datatype in the sproc from int -> bit (maybe there was a cast/convert in there that got removed)
4. an installation of .NET 3.5 across all of our production servers a few months ago, and the dates do seem to coincide with the change in the log files,

I’ve trawled google for that last hour or so looking for changes between .net 2.0 & .net 3.5 but nothings jumping out at me.

Can anyone shed any light on this ?

Answer 1

You could rebuild your code for .NET 2.0 and run a test to see if the code base you have now outputs 1/0 or true/false. That should provide you your answer. Also, it’s not really boolean.ToString() that you’re calling in this case. It is the data reader, using the default collection and casting. It may be that datareader changed how it outputs bit fields when to string is called on them.