SimplyGold

If you didn't know the using statement given in the title is valid, then congratulations! Now you do. ;-)

Why would you use this instead of the more general using Earth.LivingBeings.HomoSapiens.Female? Well:

To Avoid Conflicting Class Names

Suppose you Autopsy.cs uses both Earth.LivingBeings.Humans.Female as well as the Earth.LivingBeings.Monkeys.Female classes. One way to resolve the naming conflict is to laborously type out the fully-qualified class name each time you use it. The other way is to:

using HumanFemale = Earth.LivingBeings.Humans.Female;
using MonkeyFemale = Earth.LivingBeings.Monkeys.Female;

protected void Page_Load(object sender, EventArgs e)
{
 try
 {
  MailMessage message = new MailMessage(
    "from@example.com", 
    "to@example.com", 
    "Some Important Message", 
    "This is a test message and it's not that important.");

  SmtpClient client = new SmtpClient("your.smtp.server.com");

  System.Net.NetworkCredential credentials = new 
    System.Net.NetworkCredential(
      "username", 
      "password");

  client.UseDefaultCredentials = true;

  client.Credentials = credentials;

  client.Send(message);
 }

 catch (Exception ex)
 {
  Response.Write("Whoops! Couldn't send the e-mail: " + 
    ex.ToString());
 }
}

Storing binary data directly in the database is a fairly common practice. I recently found myself wondering how to read binary data from the database and write it to the browser.

For example, suppose you have a PDF file stored in the database. How do you send it to the browser? I ended up with this:

protected void Page_Load(object sender, EventArgs e)
{
 using (SqlConnection connection = new SqlConnection("Connection string goes here"))
 {
  connection.Open();

  using (SqlCommand command = connection.CreateCommand())
  {
   command.CommandText = "dbo.GetPdf";
   command.CommandType = CommandType.StoredProcedure;

   command.Parameters.AddWithValue("@Id", 1);

   using (SqlDataReader reader = command.ExecuteReader())
   {
    if (reader.Read() == false)
    {
     return;
    }

    int contentLength = Convert.ToInt32(reader.GetBytes(0, 0, null, 0, int.MaxValue));

    byte[] buffer = new byte[contentLength];

    reader.GetBytes(0, 0, buffer, 0, contentLength);

    Response.ContentType = "application/pdf";

    Response.BinaryWrite(buffer);
   }
  }
 }
}

This works, but I wonder if it's the most efficient way to solve the problem? For example, we're calling the GetBytes method twice, which means that we're actually reading the whole document just to get its length. If the document is huge, this is wasteful. In that situation, I'm guessing having a fixed-sized buffer and reading the data in a while loop would be the way to go.

EXEC sys.sp_tables

But this will list every single table, including all the system tables, which we rarely ever want. To list only tables created by the user, add a @table_owner parameter. For most databases, this will be "dbo":

EXEC sys.sp_tables NULL, 'dbo', NULL, NULL, NULL

Before we get on with the article, a couple of quick announcements. Regular readers of this site know well my tendency to put this site through an obnoxious number of redesigns. Sometimes I feel like I'm in a never-ending design cycle, because I'm always tweaking something here or adding something there. Anyway, I once again found myself twitching to do a redesign. I hesitate to say that I got tired of the old ( well, current, as of this entry ) theme, because I still like it; however, it most definitely grew old. So: look for the new design soon — like over the weekend; definitely over next week. :-)

Moving on.

Catching Exceptions in a Method

public void DownloadPdf(string path)
{
 try
 {
  System.IO.StreamReader reader = System.IO.File.OpenText(path);
 }

 catch (System.UnauthorizedAccessException ex)
 {
  // Hey, you don't have access to the file!
 }

 catch (System.IO.FileNotFoundException ex)
 {
  // Hey, the file doesn't exist
 }

 catch (Exception ex)
 {
  // Something bad happened
 }
}

Catching Exceptions at the Page Level

protected override void OnError(EventArgs e)
{
 Exception exception = HttpContext.Current.Server.GetLastError();

 // Inform the user about the exception, log it, and do whatever 
 // else you want to do here.
}

Catching Exceptions at the Application Level

// In global.asax
protected void Application_Error(object sender, EventArgs e)
{
 Exception ex = HttpContext.Current.Server.GetLastError();

 // Do whatever with the exception here.
}

You might notice that catching exceptions at the application level is remarkably similar to catching them at the page level. This is good — one less thing for us to have to remember. :-)

Clearing Errors

What if you want to have your application continue on its merry way, not stop dead in its tracks because of the exception? For example, suppose the user is trying to upload a file and your application throws an exception because the file is too big. It would be nice if your application lets the user to continue working instead of taking him to the jarringly-ugly yellow page of death error page?

This is what happens when you catch an exception (aka, method 1), so you don't need to do anything special. However, it's a pain to have to wrap every single method in a try...catch block. The way to clear exceptions/errors with the other two methods is with the Server class' handy ClearError method:

 // In global.asax
protected void Application_Error(object sender, EventArgs e)
{
 Exception ex = HttpContext.Current.Server.GetLastError();

 // Do whatever with the exception here.

 HttpContext.Current.Server.ClearError();
}

Conclusion

You should, at some point, trap all exceptions that occur in your application. At the very least, you should redirect the user to a custom error page. Not only are the default error pages produced by ASP .NET horrendously ugly, they're usually unhelpful to the end-user. Also, they reveal information about your code, which is bad from a security-viewpoint. ASP .NET provides 3 very easy ways to trap errors in an application.

My favorite method — well, my second favorite method — of catching exceptions is using the Global.asax's Application_Error method. ( My favorite way is to use HttpModules, which I'm going to talk about in a future article. )

exec sp_stored_procedures

That's it. That single line/word will list all the stored procedures in the currently-active database.

DatabaseName.dbo.sp_stored_procedures

This line lists all the stored procedures in the specified database.

Another useful stored procedure is sp_helptext, which shows you the actual (SQL) stored procedure:

DatabaseName.dbo.sp_helptext StoredProcedureName

Using these stored procedures with a linked server is straight-forward, too:

NameOfTheLinkedServer.NameOfTheDatabase.DatabaseOwner.sp_stored_procedures

This is something I seem to be doing an awful as of late. I start out with some control (say a GridView), then switch to some other control (say a Repeater), but I don't want to delete the GridView control until I get the Repeater control working.

You might have tried commenting out the control the HTML way — i.e., <!--...--> — and you probably found out that ASP .NET engine still parses it. Until recently, I was dealing with this the hard way: cutting & pasting the control into Notepad.

No longer.

Enter Server Comments

Namely:

<%--

 <asp:GridView ID="ProductsGridView" runat="server" DataSource="ProductsDataSource">
 </asp:GridView>

--%>

ASP .NET will ignore everything within a server comment block.

Suppose you're showing a list of customers, and you want to highlight any customer who'd been with you since before 1920. Maybe you also want the JoinedOn field to show the number of months for customers who've been with you for less than a year. It's fairly easy.######Add OnRowDataBound Handler to GridView

The easiest place to change the data is just after the data gets bound to the row. So:

<asp:GridView runat="server" ID="CustomerGrid" OnRowDataBound="CustomerGrid_OnRowDataBound">
</asp:GridView>

Make the changes in CustomerGrid_OnRowDataBound

protected void CustomerGrid_OnRowDataBound(object sender, GridViewRowEventArgs e)
{
 GridViewRow row = e.Row;

 // Make sure we aren't in header/footer rows
 if (row.DataItem == null)
 {
  return;
 }

 Customer customer = row.DataItem as  Customer;

 if (/* Do your conditionals here*/)
 {
  // Change Row formatting here OR
  // Add new cells 
  // Or create an entirely different cells
 }
}