Aug 102005
 

I have read too many articles showing the connection being opened and closed around a DataAdapter Fill() as in the code below. It does no harm, but it not necessary.


Don’t do this…


SqlCommand command = new SqlCommand(“usp_MyQuery_Select”, this._con);
SqlDataAdapter adapter = new SqlDataAdapter(command);
DataSet ds = new DataSet();
try
{
   this._con.Open(); //unnecessary
   adapter.Fill(ds);
}
finally
{
   this._con.Close(); //unnecessary
}


Do this…


SqlCommand command = new SqlCommand(“usp_MyQuery_Select”, this._con);
SqlDataAdapter adapter = new SqlDataAdapter(command);
DataSet ds = new DataSet();
adapter.Fill(ds);



If you track SqlDataAdapter’s Fill() method in Lutz Roeder’s .NET Reflector, you will see that it ends up at DbDataAdapter’s FillFromCommand() method. FillFromCommand() opens and closes the connection in a try-finally block. Making this unnecessary in your own code.


Disassembled from Reflector


private int FillFromCommand(object data, int startRecord, int maxRecords,
   string srcTable, IDbCommand command, CommandBehavior behavior)
{
   IDbConnection connection1 = DbDataAdapter.GetConnection(command, “Fill”);
   ConnectionState state1 = ConnectionState.Open;
   if (MissingSchemaAction.AddWithKey == base.MissingSchemaAction)
   {
      behavior |= CommandBehavior.KeyInfo;
   }
   int num1 = 0;
   try
   {
      try
      {
         DbDataAdapter.QuietOpen(connection1, out state1);
         using (IDataReader reader1 = command.ExecuteReader(
            behavior | CommandBehavior.SequentialAccess))
         {
            if (data is DataTable)
            {
               return this.Fill((DataTable) data, reader1);
            }
            return this.Fill((DataSet) data, srcTable, reader1, startRecord, maxRecords);
         }
      }
      finally
      {
         DbDataAdapter.QuietClose(connection1, state1);
      }
   }
   catch
   {
      throw;
   }
   return num1;
}


Aug 062005
 

Most developers cringe when they hear the words “Coding Standards.” A developers coding style defines them. Their style has been molded over the years into what it is today. Telling a developer that their way is not the “right way” is difficult and sometimes taken personally.


Coding standards are, however, an important part of every project. Deciding on coding standards often happens too late when there is too much code in too many different styles. It is important to every developer to have and appreciate standards because we will “inherit” someone elses code. It would be nice if we could read it.


I recently got the chance to review David McCarter’s 53-page book titled “VSDN Tips & Tricks .NET Coding Standards.” I loved it! It combines coding standards from Microsoft and other sources (not to mention common sense) into one easy-to-read “guide.” Its focus is on Visual Studio .NET 2003 with v1.1 of the Framework. That doesn’t mean that you Beta 2 snobs can’t read it! It provides C# 🙂 and VB 🙁 examples and covers a variety of topics from indentation and word choice to event and exception handling.


I have seen most of the suggested standards in various other white papers and on MSDN. It’s a great book to compare against your company or personal coding standards. Not everything in this book will make sense to every shop. Personally, I found only a few items that I don’t already use (one of which being the use of Event Accessors instead of using public event member variables.)


Definitely worth reading. Find out more at http://www.vsdntips.com