Andre's Blog

Personal blog of Andre Perusse

New Car Search: T-55 Days And Counting









On The Edge (and falling off a cliff)








Rules for Checking In Code to Source Control

The golden rule of checking in code is:

Don't check in code that will break the build.

Nobody likes code that won't compile. Also see Scott Hanselman's First Rule of Software Development.

In order to help verify that your pending check-in will continue to result in a healthy build, you may wish to view the following rules and procedures that I find helpful.

  1. Try to work on small chunks of code and features at any given time. As Tim Stall points out, "It's easier to integrate 5 small things than 1 big thing."

  2. Before checking in anything, perform a "get latest" on your entire solution's code-base. Resolve any version conflicts before proceeding.

  3. If you have any web sites in your solution that have references to web services, make sure you update all web references.

  4. Perform a build on your entire solution. Obviously, fix any compilation errors.

  5. Database scripts. Ahhh, these are lovely, aren't they? Unless you're fortunate enough to be using some cool database tools (like Visual Studio for Database Professionals), you don't likely have any compile-time error checking for your database scripts. It is essential that you ensure all your database scripts for changing the schema, updating the programming (e.g., stored procs), and inserting default foundation data work properly. If they don't, you'll soon have a swarm of angry developers beating down your door. The best way to do this is to run the update scripts on your machine and test the software. Update scripts should be written in such a way that they first check to see if a particular update has been applied first before trying to apply it again. This makes it much easier to test, and for other developers to apply to their database copies.

  6. Check in ALL files you have checked out. This is a tricky one, since perhaps you know that a particular file doesn't work properly, even though it will compile properly. Unfortunately, you may not know what dependencies exist on this file from some of the other files that you're checking in. So, while you may think you're doing a favour for the rest of your development team by not checking in a file you know to not work properly, you may actually be more causing grief by checking in code that won't build!

Even if you use a fancy-shmancy tool that performs delayed commit or source integration (such as TeamCity), as a professional developer you should really follow these guidelines to save yourself (and your team) pain and suffering.

XBox 360 Fun








SQL Server 2005 Syntax Incompatible with SQL Server 2000

CREATE TABLE [dbo].[Order](
 [orderID] [int] NOT NULL,
 [customerID] [int] NOT NULL,
 [orderDate] [datetime] NOT NULL,
 [shipDate] [datetime] NOT NULL,
 [shipperID] [int] NOT NULL,
 [shipperTrackingNumber] [varchar](50) NULL,
 [orderID] ASC
Line 11: Incorrect syntax near '('.
CREATE TABLE [dbo].[Order] (
 [orderID] [int] NOT NULL ,
 [customerID] [int] NOT NULL ,
 [orderDate] [datetime] NOT NULL ,
 [shipDate] [datetime] NOT NULL ,
 [shipperID] [int] NOT NULL ,
 [shipperTrackingNumber] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE [dbo].[Order] ADD
Run this on SQL 2000 and you'll get:
Invalid object name 'sys.foreign_keys'.
Also, the following code is used by SQL 2005:
DROP TABLE [dbo].[Order]
which will give you the following on SQL 2000:
Invalid object name 'sys.objects'.
DROP TABLE [dbo].[Order]

The Easy Way To Alternate Background Colours on a Repeater




Or, in C#:



A Cool ASP.NET 2.0 Feature (Well, Almost)

Whenever I start a new web project, one of the first things I do is create a "Base" class for all my ASPX code-beside ("code-behind" is so .NET 1.1) class declarations to inherit from. This makes it easy to have useful properties such as CurrentUser available in all pages automatically. Such a practice is quite common these days, and has been covered in several articles including this one.

Recently, I have found it useful to have some boolean properties on the base class which control the rendering of certain elements. For example, a current project I'm working on has the requirement to restrict the user's ability to navigate backwards by using the browser's "Back" button. This is accomplished via the use of the JavaScript "history.forward()" hack. Now, some pages in the application require this while others do not. So the best way to handle this is to have a base-class property called DisableBackButton and set it to "true" when I want to prevent the user from going back to the previous page. And, in fact, this is what I did and it works well.

However, setting such properties can only be achieved with programmatic code. For example, to turn this property "on" for a certain page, I would have to write "DisableBackButton = true;" in the Page_Load event handler. This is fine, but it feels "dirty" and unsophisticated to me. I would much prefer to set this property in a "declarative" fashion on the actual ASPX file rather than writing code to set it. Say, wouldn't it be cool if I could just add an attribute to the @Page directive that said DisableBackButton="True"? Well, it turns out that in ASP.NET 2.0, you can do exactly this!

Well, almost. If you read all the comments in that link you'll see that it isn't all that simple, unfortunately. First, if you're using a base class like I am, you also have to set the "CodeFileBaseClass" attribute in the @Page directive. Ick. I think this is something that the compiler can determine for itself without me having to tell it explicitly. Requiring me to add it manually just means there's another possible point-of-failure and yet something else that has to be maintained. Still, it's not a too terrible price to pay for the cool declarative property setting feature I'm trying to achieve. But, that isn't the only problem. While the project will now compile, you'll still get ASP.NET validation errors in all your pages saying that "DisableBackButton" is a not a valid attribute for the @Page directive. Grrrr. To stop this message from clogging your Visual Studio errors window, you have to open up Visual Studio's XML-based schema file and add the attribute. Now this is really a problem since this schema file is used for ALL Visual Studio web projects, not just the one you're working on right now. And it also means that if you share the code with someone else, you have to tell them to go modify their schema file, too. This is completely unacceptable.

In the end I decided to go the old-fashioned route and set this property programmatically in each page that needed it. While the declarative route would have been uber-cool, there are just too many road-bumps down that path. Here's hoping Orcas (or Shamu as my wife calls it) does something to address this problem.

Making Reporting Services Work On Vista (64-bit)

A couple of weeks ago I got a new laptop (that went along with my new job) and at the urging of some on my co-workers (and against my better judgement) I installed Vista Enterprise 64-bit on it. And that's another story all together. I also installed SQL Server 2005 (64-bit, naturally) and after fighting with the new IIS 7 on Vista (see this Microsoft Support Article for more info), I managed to get Reporting Services installed too.

However, I had never configured it until today. I brought up the Reporting Services Configuration Manager and focused my attention on the first "red X" in the list, which was the "Report Manager Virtual Directory." I was able to set up the virtual directory, but the damn red X wouldn't turn into a green checkmark no matter what I did. I searched the Internet and found all kind of Reporting Services on Vista horror stories, but no story that fit my exact problem. After looking at the various Reporting Services .config files for clues, I went back to the Configuration Manager window and clicked on the "Report Server Virtual Directory" item, which had a green checkmark. Aha! The damn thing WASN'T set up, even though it had a happy green checkmark. Once I set up both the Report Server and Report Manager virtual directories with the proper application pool settings outlined in the above referenced Microsoft Support article, I was able to complete the Reporting Services configuration and now it works great!

Moral of the story: don't trust green checkmarks - they're not always correct.

Amiga Rumour Mill In Full Swing

Well, following up on my complete surprise to learn that AmigaOS was still being developed, it now seems as though the arrival of new Amiga hardware is imminent! Though I'll believe it when I see it, it's nice to see that there are still some die-hard Amiga addicts out there.

To see the details of the new hardware announcement, check out these press releases from

And while Amiga is no longer owned by the management-challenged Commodore of the early '90s, it's seems they're still up to their old tricks of questionable tactics. The mainstream personal computer industry has pretty much given up on PowerPC, but Amiga has chosen it as their CPU. Curious. Add to that the decision to use a 66MHZ PCI slot for the graphics card? Holy crap - that predates AGP which is now obsolete! I'm not sure what their business plan is, but I really can't see too many people buying these things. Still, it will be interesting to see what develops.

I wonder if it will still run Speedball?  :-)

Microsoft Adds Powerful Tool For Database Developers

I've been dying to try out Microsoft's latest addition to the Visual Studio Team Suite set of products - Data Dude, or more properly know as Visual Studio 2005 Team Edition for Database Professionals. Recently I finally took some time to watch a series of webcasts (at 1.5x speed - the only way to learn!) on MSDN and figure out how this thing works. After spending a couple of hours watching these webcasts, I am able to present you with the Coles Notes version of what Data Dude does and how it works.

Data Dude essentially represents your entire database as a series of text files. You can think of this as the "source code" for your database. Individual .sql files (which are just text files) containing DDL (data description language - SQL commands that create database objects) are stored within the new "Database" project type in Visual Studio. So, if you want to create a new table called "Customer" for example, Data Dude creates a new .sql file called "Customer.sql" which contains the DDL commands to create that table. In this respect, it's not a whole lot different than the old Visual Studio "Database" projects where you might have manually stored .sql scripts to keep them under version control.

What Data Dude brings to the table, however, is a lot more automation and validation to this entire process as well as the ability to "build and deploy" your database to any SQL Server instance. So, you have this big collection of .sql scripts to create tables, views, indexes, procedures, and functions and Data Dude does this wicked cool thing where it "parses" all the SQL in these files and validates them. So, if you a .sql file for your Customer table and it contains a field called "customerID" and in the .sql file for a stored procedure that SELECTs from that table you have written the field as "custID", you'll get a build error! Nice stuff.

You can either start your database project from scratch, or you can reverse engineer from an existing database. Once you have a your database project in a state where you're ready to deploy it, you can perform a deployment operation against any SQL Server instance that you can connect to. Data Dude will examine the differences between the source files it has and the existing database on the target and only deploy those updates that are required. For a new database this would obviously be everything, but for a database that your reverse engineered and only changed one stored procedure for example, only that stored procedure is changed on the target. Sweet!

Now that your database is represented as simple text files, you can easily place your database definition under source control. One of the problems that I've experienced working with a team of developers is that while the procs and functions might be under source control, the schema (tables, views, etc.) generally isn't. So, one developer might make a schema change on their local SQl Server instance, update a proc too, check-in the proc, but forget to tell other developers about the schema change. Naturally, when another developer tries to apply the latest version of that proc against their development database, it blows up. Data Dude does away with that by making it oh-so-easy to put your entire schema under source control. So now, another developer can get the latest version of the database project from source control, do a deploy against their local development SQL server, and the schema change AND the proc will get updated.

In addition to providing features for comparing schemas, it also allows to perform data comparisons between tables in different databases. So during development when you're adding new rows to lookup tables, for example, you can now easily deploy those updates to another database (such as a testing or production system) by performing a data compare.

But wait! There's more!

Data Dude also adds the ability to run unit tests against your database. Using Visual Studio 2005's existing unit testing framework, you can create tests that run against your tables, procs, or just about anything. To help you with this, you can create Data Generation Plans that automatically fill your tables with random data. You have a lot of control over how the data is generated, including number of rows and minimum and maximum values. So, the ability to run unit tests combined with the automatic population data makes for a very powerful combination to help you write quality database code.

If you can, I'd recommend that you spend a few hours with Data Dude learning how to take advantage of its capabilities. It may be a "release 1" product and while it's not perfect, it's still a great tool for database development in a team environment. And when they add ERD diagramming features in the next release or two, it will be the only way to develop databases.