Do you remember this?

Or how about this?

Or maybe this one?

If so, you might find this link interesting. It shows the process of upgrading a system from the first windows operating system all the way to Windows 7.

Warning, if you are a dyed-in-the-wool believer that Microsoft is the evil empire, you may find yourself spewing profanities at your browser and asking no one in particular how Windows can survive for some twenty plus years.  For the rest, take it as a reminder (or history lesson) of the evolution of a tool that a lot of us have used for a long long time.

I think a good habit you can get into as a developer is to think about several ways to tackle a task instead of implementing the first solution that pops into your head.

For example, a client recently decided they wanted to duplicate one of their sites.  So we copied the code and the database. (The site’s data is stored in a Sql Server database.)  Part of the database contains data used for reporting purposes. The new users have access to this data but will not be updating the data. At first glance, if we used the copied database as is, we would need to duplicate the process that populates the reporting tables. However, we don’t want to go that route.  In addition to storing two copies of the same data, changes to the process would require coding the same updates in two different places.

The next idea was to change the all the database calls that reference the reporting tables to access the data from the original database.  This would work but would require changing a lot of calls in several stored procedures that are used to pull the reporting data from the database.

How do we access the data without changing any of the select statements wherever they may be? We then set up a view in the same name as each of the tables from which we wanted to access data from the original database.

Say we have a table named “products” in the original database.  We didn’t include that table in our new database. Within the code on the new site, the select statement might say something like SELECT name, color, weight FROM product.  If we changed the select to pull from the original database, the select statement would look like SELECT name, color, weight from originaldatabasename…product.  Instead of doing this, define a view named Product. This view contains the select from the original table. Now any Select statement that needs data from the original table has access to the data in the table via the view.

This saves time now and in the future in that we don’t have to change all the Select statements to access the Original database’s tables.

Not long ago one of our clients needed some special Meta tags on a few of their pages.  Like Vladimir and Estragon, they anxiously awaited those tags. Needless to say, these tags, unlike Godot, were quick to make an appearance.Their site was developed using Visual Studio 2005 and made extensive use of several master pages.  Rather than creating new master pages for each of the meta tag sets, I wanted to be able to set the meta tags within the confines of the existing master page. So, I went to Google and found a few links that showed me the way.

ASP.Net 2.0 – Master Pages: Tips, Tricks, and Traps

Specifying the Title, Meta Tags, and Other HTML Headers in the Master Page

Using Meta Tags with Master Pages in ASP.NET

I used the “Header Place Holders” method described in the  Tips, Tricks and Traps link.  This enabled me to add the Meta tags to the content page without creating code behinds for each page.

I was going to write about the Peloponnesian War, its ramification on the course of Western Civilization and how that ancient struggle correlates to the Microsoft vs. Apple battles we see today. But, in addition to the fact that I really don’t know very much about the Athenians or Spartans, that war was fought, as my son Tyler would say, “a very long long day ago”.  Instead I’ll write about how in ASP.NET you can prevent an error from being written to the server’s application log.

Let’s look at the “A potentially dangerous Request.Form value was detected from the client“ error that can show up on an ASP.NET page.  This error is thrown when potential HTML or other script tags are entered into a textbox of an ASP.NET form. This error gives you something looking like …..

The error itself isn’t a bad thing since it helps prevent script injection attacks.  (If you want to allow script tags to be entered on your form there are several things you can do. Check them out here.) Our problem was that when an unaccounted for error is thrown in ASP.NET, the error is written to the server’s application log. We have a utility that reads the application log and email’s the system administrator any errors that show up. Our administrator had to screen all of these emails in looking for one’s that we really needed to see.

The solution is to put some code into the Application_Error method of the global.asax file that will trap and remove the error that we don’t want to log.

Notice that after clearing the error we need to redirect to another page. If, after clearing the error, we allowed the page to load, we would see a blank page. (The error that would have been displayed is erased by the Server.ClearError() command).

You could also include the code in the page’s “Error” event.  However, you would have to include the code on every page instead of in just one place.

So, if you have any interest in preventing an ASP.NET error from being written to the server’s Application log, consider using the Application _Error method of the site’s global.asax