memory.Refresh()

SQL Server 2005 introduced a new feature called the output clause. This enables INSERT, UPDATE and DELETE queries to be run, with the original information which has been changed being returned. This is particularly useful if you want to run a query and know what has been changed by it by returning the identites of the modified rows.

The full documentation for the output clause can be found in SQL Server 2005 Books Online.

In trying to use this feature, I could get it to work in a query window, but when trying it using C# and ADO, it was not obvious how to execute the query and return the results because the ExecuteNonQuery() method of SqlCommand only returns the count of the number of rows that have been updated. After a bit of unsuccessful searching, I came across a post by Keyvan Nayyeri with something that gave me an idea:

OUTPUT clause works like a SELECT statement but its usage differs in INSERT, UPDATE and DELETE commands

Switching my code around to run the update query using the ExecuteReader() method of SqlCommand as would be used for a SELECT query proved to be fruitful, enabling the returned result set to be read.

Aaron Stebner has compiled a list of which version of the .Net Framework is included in which version of Windows by default:

^{* although it appears as an OS component, it is actually just an MSI based installer.}

The MSI based installers can be used to install or uninstall the .Net Framework from the OS, enabling it to be removed completely if needed.

Very useful if you are targeting specific platforms with your .Net applications.

If you are using the AssemblyFileVersion attribute to mark your compiled assemblies with specific Win32 file version numbers, you may get a compiler warning with certain revision numbers. The compiler warning looks like this:

warning CS1607: Assembly generation -- The version '2.0.0.070105' specified for the 'file version' is not in the normal 'major.minor.build.revision' format.

This warning is documented as occurring when the version string is not in the major.minor.build.revision format, but does not explain why it happens for the example above.

Frans Bouma updated his existing post with the reason why. The revision part of the version number must not exceed 65535 (ie. a 16-bit number). If it does, the compiler generates the warning. The MSBuild Team posted about the same thing, but also provided the fact that it is the underlying operating system that imposes this limit.

Having done several installations of Windows over the years and always chosen the “quick format” option over the normal format option (mainly due to the time it takes to do a full format compared to a quick format), I finally looked into what the differences between the two are. Microsoft’s site has a knowledge base article about this very thing.

A full format will wipe the disk, format it and run a check disk to find any bad sectors. A quick format will wipe the disk and format it, but will skip the check disk stage. As it turns out, the check disk stage is the thing that causes a full format to take a lot longer than a quick format.

If formatting a new hard disk, it is probably wise therefore to do a full format to find any sectors that may have been damaged whilst the disk was in transit. If formatting an old disk, it is already in a known state and so a quick format should suffice.

There’s a nice little section on Microsoft’s MSDN site entitled The C# Programming Language for Java Developers that explains the basics of the C# language features.

Although not incredibly detailed, it’s quite a useful reference for simple language information, especially about the system types (such as the range of a double or what types can be implicitly cast to a short).