The SqlBulkCopy object is good, but probably buggy. The fact that it is case sensitive to columnames to me is a sign of likely low code quality, and the error that gives this blog entry its title is another.

Sometimes bulk copy will import a table from text without explicitly setting the columns. Sometimes you have to explicitly set the columns and poof! it works. It may have to do with white space or case sensitivity in the columns, or it may have to do with drivers making inaccurate counts of fields.

SqlBulkCopy bcp = new SqlBulkCopy(
“Server=.;persist security info=True;initial catalog=target;Integrated Security=SSPI”,
SqlBulkCopyOptions.KeepIdentity & SqlBulkCopyOptions.KeepNulls);

bcp.BatchSize = 50000;
bcp.ColumnMappings.Clear();

for (int i=0;i {
string name = reader.GetName(i).Trim().ToLower();
bcp.ColumnMappings.Add(name,name);
}

for (int i = 0; i < bcp.ColumnMappings.Count-1; i++)
{
System.Diagnostics.Debug.WriteLine(bcp.ColumnMappings[i].SourceColumn);
}
bcp.DestinationTableName = file.Name.Split('.')[0];

bcp.WriteToServer(reader);

bcp.Close();

NOTE: Even explicitly listing the columns often is not enough. I eventually gave up and used alternate techniques. The command is poorly documented with respect to what text formats are acceptable for BIT, DATETIME, IMAGE when doing heterogeneous bulkcopy. Until MSDN documents it, this otherwise fantastic tool is only reliable for copying from SQL to SQL with identical schemas and probably identical version and patch levels.

In the good ole days, if we hit an error message, we’d just write to the console a routine insult to the user.

If input_arg<0 then Print “You are such a dumb ass”

We now hide our contempt in secret code

If input_arg<0 then Print “Please contact your administrator”
/* You are such a dumb ass */

Sometimes we prefer the “I’m smarter than the runtime” pattern and send developers on a goose chase.

I beseech the developer community to swear to never use #region or #endregion blocks again, except for possibly machine generated code.

The first step is to stop typing #region and #endregion. This will greatly improve the transparency of your code. Next, because you are the sort of person that uses #region and #endregion to hide the code you are ashamed of– go find all those HACK:, BUG:, and CRAP: comments.

You will get a YSOD, but the finally block executes before the YSOD.

try
{
int bar = 1 / int.Parse(this.TextBox1.Text);
int z = 21;
z++;
}
finally
{
int foobar = 1 + 1;
}

This is kind of like a IDisposable patter at the method and code block level. It means, on the way out of this code block, I want some clean up code to run. Off hand I can’t think of a good reason for this if you aren’t releasing resources. Using it as a control of flow technique looks very iffy especially if it wasn’t the error you were expecting.

Identical behavior to the above, YSOD, but finally block runs just before the YSOD. The following is code you’d see in code generation scenarios where the try/catch/block is code generated with the hope that the developer would fill better error handling later.

try
{
int bar = 1 / int.Parse(this.TextBox1.Text);
int z = 21;
z++;
z++;
z++;
}
catch (Exception) {
throw;
}
finally
{
int foobar = 1 + 1;
}


YSOD after line one, no other code after the error is executed

int bar = 1 / int.Parse(this.TextBox1.Text);
int z = 21;
z++;
z++;
z++;
int foobar = 1 + 1;


How often do you see this pattern (or variations on it)

try{
…some code…
}
catch{
throw;
}

Sometimes it will be catch(Exception ex) or catch(SomeParticularException ex), and sometimes it will be throw; or throw ex;, there is no finalizer block, but the important thing is that NO OTHER ACTION IS TAKEN (no logging, no retry, nothing else in the catch block).

As far as I can tell, this is equivallent of wrapping code in NOP (no-operation) commands.

Please don’t do this.

I researched options for testing my ASP.NET website. I decided to use Scott Hanselman’s solution where simulate IIS using Cassini and simulate a browser using WebClient.

Good Points
It works!
It’s free!
Doesn’t require a massive refactoring or rewrite.

Challenges
Cassini should be a singleton. Unless you are testing something that is IIS dependent, you should not destroy Cassini inbetween each test or test fixture.

My theme here are general purpose programming attributes, ones that you might use for any class.

(first seen here)

DebuggerStepThroughAttribute, [DebuggerStepThrough()]
You can still set breaks here, but normally the debugger will fly right over it. Use this when you find yourself running through the same boiler plate code over & over again, especially if the code is machine generated, or otherwise not of interest.

DebuggerNonUserCodeAttrbute.[DebuggerNonUserCode()]
No step through, no breaking, even if you have a breakpoint.

[DebuggerDisplay(