11 Programming Mistakes You Don’t Even Realize You’re Making

Disposing Objects Properly

The ‘using’ syntax doesn’t get nearly the kind of exposure it should, and it’s all to easy to not understand which objects need to be disposed of properly, and for which it doesn’t matter. For example, I bet you realize that SQLConnections should always be closed, and disposed of, but what about StringWriter? It too needs proper attention.

using (StringWriter myStringWriter = new StringWriter())
	// . . .
using (SqlConnection con = new SqlConnection(myConnectionString))
	using (SqlCommand cmd = new SqlCommand(stringSQL, con))
		// . . .

Filling Your Database With Bad Data

User input. We love it, we hate it, and most of the time, it defies our expectations in one way or another. Here are some ways you probably aren’t properly taking care of your data:

  • proper capitalization of names
  • trimming leading and trailing spaces or zeros
  • verification of birth-dates : leap years, and improbable ages (a user registering who says they are 110 years old? Or, that they are only 2 years old?)
  • data encoding and decoding, especially for HIPA requirements
  • along the lines of multi-line or rich-textboxes, cleaning up HTML where there shouldn’t be any or removing MS Office meta-data from naive users’ copy-paste operations
  • length restrictions both in your code and on your database – so your FirstName field doesn’t take up VARCHAR(MAX) disk space

Shooting Yourself In The Foot With Lack of Documentation (Or Comments)

Simply put, the proper amount of documentation is near impossible to achieve. While we shouldn’t be writing novels in our code, they should quickly jar our memory when we need to revisit them a few years later. Whether it’s specification documents, contracts, or comments, it’s all to easy to fall short.

Slowing Your Own Server Down With Debug Mode

Debugging is great for us developers, but in production servers, it takes up extra processing power.

<compilation debug="true">

Unnecessary Post Back Operations

While intermediate developers are probably aware of the IsPostBack feature, new ones may not be, causing unnecessary operations – which usually involve database calls

Unusual Circumstances Bypassing Your Data Validation

Did you know that sometimes your submit button’s onclick or onclientclick method can be called even though your validators have errors? It is true! Checking Page.IsValid will save heartache and mysterious bad data.

if (! Page.IsValid)
// return to the page - the validators will now show their error messages

Sluggish Server Responses Via UpdatePanel

Although it seems like magic, ASP.NET AJAX’s UpdatePanel has some necessary flaws, and it’s important to know them. When UpdatePanel updates asynchronously, it performs a postback by sending the data of everything inside it via HTTP. Now, if you have a lot of data inside your UpdatePanel, this update is going to be very slow.

Crashing Your Own Server With Session Data

If you’re storing a lot of stuff in your Session variables, be warned, this can act like a DOS attack on your server (OWASP, more info). Basically, SessionData takes up memory, and with enough users, it begins to act like a memory leak.

Query Variable Injection

Query variables can be useful, but also terrible, as it exposes data to the user for all-too-easy manipulation any dabbler can play with. SQL injection is also something to watch out for, however the fix for this can be as simple as using ASP.NET’s built-in parametrized queries.

Leaving Document, HTML Files Insecure

By default, IIS only applies your security settings (usually in your web.config file) to ASP and ASPX files, leaving any images, HTML, or other document files open for anyone who has the URL. To fix the problem, special settings can be applied to IIS.

Tying Your Database’s Hands Behind Its Back With Lack Of Keys and Indexes

MS SQL Server, and other servers, have out-of-the-box optimizations that make your queries run surprisingly fast. However, they all depend on the query analyzer being able to pick up on ways to speed up the query. Basically, when you don’t use keys or indexes, the query analyzer doesn’t know what to do with your data, and thus can’t really make any optimizations. As a result, it defaults to the most reliable way of doing things, which is consequentially, the slowest.

MSSQL Drop Database Errors & WorkArounds

‘sp_delete_database_backuphistory’ Errors

If you’re trying to delete a MS SQL database and you get errors like this :
Delete backup history failed for server ‘MYSERVER’
The EXECUTE permission was denied on the object ‘sp_delete_database_backuphistory’

The workaround is very simple. Open up your query editor and drop it manually, like so:


‘Database In Use’ Error

If you get an error like :
Cannot drop database “NorthWind” because it is currently in use.

You can fix it by using this instead:


How to Restore MS SQL Differential and Full Backups

1. Create a new database with desired name.

2. Do a restore full backup.

– Find your new database’s name as the ‘To database’, leave the point in time alone, and speicfy the ‘From device’ as your full backup file. In the options screen, you will want to choose ‘Overwrite the existing database (WITH REPLACE)’.
– If this is your only backup, choose the default recovery state option, RESTORE WITH RECOVERY; press the button and you’re done. If you have differentials you will be restoring as well, choose ‘Leave database non-operational (RESTORE WITH NO RECOVERY).

3. Do your differential backups one at a time, in sequential order.

– For each backup, choose the ‘To database’ to same as before, ‘From device’ as your backup file.
– In the options panel, if you still have more differentials, leave all the defaults, and choose ‘Leave database non-operational (RESTORE WITH NO RECOVERY)’ for Recovery State.
– If this is your last/final differential, leave the defaults and for Recovery State, instead, make sure ‘Leave database ready to use (RESTORE WITH RECOVERY)’ is chosen.
MS SQL Server "Restore Database" Wizard

MS SQL Server "Restore Database" Wizard