Joe Field

SQL Server Isolation Levels

Thanks to Andy Grout for working this stuff out with me...

All isolation levels affect the way in which you read data. They also affect the way others can update data because the type and duration of the locks differ.

Read Uncommitted

• Takes out no locks when issuing SELECT statements

• So you can read other transactions' uncommitted data i.e. dirty reads

Read Committed

• Prevents dirty reads

• Takes out a shared lock when issuing a SELECT statement (this prevents updates)

• If another transaction has an exclusive lock your SELECT will block until the other completes

• Releases the shared lock when the SELECT completes, not when the tranaction completes

• So the same SELECT later on in the same transaction might return different data i.e. non-repeatable reads

Repeatable Read

• Prevents dirty reads and non-repeatable reads

• Takes out shared locks when issuing SELECT statements and doesn't release them until the transaction ends

• So prevents any data you read from changing via updates or deletes

• But doesn't prevent new rows from being inserted into other pages

• So your SELECT statement might still return more rows the second time you execute it i.e. phantom rows

Serializable

• Prevents dirty reads, non-repeatable reads and phantom rows

• In SQL 2000 and SQL 2005 takes out key-range locks, a special type of shared lock which prevents inserts into a range of values

• Ensures a SELECT statement always returns the same results within a transaction

Excel uses old .NET runtime

MSMQ - Unable to load MQQM.DLL

So here I am starting to work with MSMQ 2.0 on Windows 2000 and enjoying myself hugely when I run into this message when trying to install MSMQ after having uninstalled it.

Error: Unable to Load MQQM.dll
Error Code: 0x7F

Luckily there is this Knowledge Base Article to help - but it ain't pretty.

CruiseControl.NET from Scratch v1.0

Just updated my article: Cruise Control .NET from Scratch v1.0.

Loads of nice changes in this version, particularly in the cctray application.  It's also even easier to set things up so the article's getting shorter! The previous article for version 0.9 is now here.

If your SourceSafe working folders are broken...

This happens to me a lot and it's easy to fix.  The symptom is that SourceSafe suddenly decides, with the aid of Visual Studio, that the working folders for a project or a whole project tree are not the ones you want.

Close SourceSafe on your client machine.  Also close Visual Studio.  Then on your SourceSafe server find the users/<yourname>/ss.ini file.  At the end of the file are the details of your working folders, a series of lines that look like this:

[$/CITest]
Dir (JFIELD) = D:\Projects\CITest

Delete the ones you don't like and save the file.

Share and Pin in Visual SourceSafe

I've found it useful from time to time to share and pin in SourceSafe when creating branches so thought I'd write it up here. The idea is that you share a labelled version, creating a new project based on that label. Each file in the project is pinned to a specific version. The advantage of this is that you need to explicitly branch each file that you intend to modify. And this in turn means that you have an easy indicator (the pinned icon) that a file has not been branched. This makes merging much easier, which can be no bad thing.

Stage 1: Share and Pin. Select the project you want to share and view its history (Tools -> Show History). Select a label. Click on the share button and select the node you want as the parent of the copied project. Don't check the "branch after share" checkbox. You will be prompted to input a name for the new project. Also select the "recursive" option This creates a new project in SourceSafe with all the files pinned to the labelled version. Do a recursive get of the new project from SourceSafe - don't use the "Open From Source Control" Visual Studio menu option.

Stage 2: Branch Solution. Branch the .sln and.vsscc files by using the Branch command from the SourceSafe menu. Then check them out.

Stage 3: Change Source Control Bindings. A nasty one this. Sometimes I manually edit the new .sln file to make the bindings point to the correct path, or if I'm feeling less gung ho I open the new solution in Visual Studio and use the "Change Source Control" menu option to change the bindings. Be aware that this can seriously damage your SourceSafe working directories. See my next post for how to fix this.

Stage 4: Working with the new project. The new files are pinned in SourceSafe - a useful visual indicator, so they need to be manually branched using the SourceSafe GUI before you can check them out with Visual Studio. Visual Studio will tell you that the checkout failed if you attempt to check out a pinned file. Select the file in SourceSafe that you need to branch and use the "Branch" command from the "SourceSafe" menu.

Stage 5: Merging changes in the branch back into the main project. Use the unpinned files as a visual indicator to help with identification of modified files. If you're feeling cautious (as I normally am) perform a manual merge using your favourite compare tool. If you want to live really dangerously, select the file in the main project and choose "Merge Branches" from the "SourceSafe" menu. Sometimes you'll see the dodgy visual merge tool, sometimes you'll receive no feedback at all!

Array Comparison in NUnit v2.2

Ran into this today. Was looking at some code written by Antony Marcano and noticed something which, greatly simplified, would amount to this:

[Test]
public void Test()
{
 object[] a1 = new object[] {"First", "Second", "Third"};
 object[] a2 = new object[] {"First", "Second", "Third"};
 Assert.AreEqual(a1, a2);
}

This test was passing. Surely this should fail. But it turns out that NUnit v2.2 changes the reference comparison semantics for arrays. From the docs:

Starting with version 2.2, special provision is also made for comparing arrays. Two arrays will be treated as equal by Assert.AreEqual if they are the same length and each of the corresponding elements is equal.

Character Set Shenanigans

For various reasons I've been working a lot at understanding character sets recently. There's a wealth of knowledge out there, not least Joel's excellent introductory article.

I also found Jon's resources very useful. And excellent character set tables here. And Ultra Edit text editor of course - which shows you Hex for Unicode, UTF8, 1252 etc.

Interesting things (for me, living in Western Europe) were:

• Typing Alt + 243 on the numeric keypad will input the character "¾". This is because it selects the code from the IBM 850 code page.
• But... typing Alt + 0243 on the numeric keypad will input the character "ó". This time the code is selected from the Western European 1252 character set.
• The Euro symbol goes walkies a bit - in ISO8859-1 (Latin 1) it wasn't present. It's in ISO8859-15 at 164 decimal. But in 1252 it's at 128 decimal. And its Unicode code point is 0x20AC.
• ISO8859-1 occupies the first 256 code positions (and ASCII the first 128 positions) of the UCS.
• Latin 1 and 1252 are identical from 160 to 255.

I could go on but someone might get sleepy.

Cruise Control .NET v0.9

At last! Cruise Control .NET from Scratch for version 0.9 is here. Now updated for NAnt 0.85 and NUnit 2.2. The previous one for version 0.7 is here.

I'm looking forward to getting into this version with a large system - multiple projects - multiple build servers - fantastic!

Cruise Control .NET v0.7

I have updated my Cruise Control .NET from Scratch article to bring it in line with version 0.7.  I have retained the previous one for version 0.6.1 here.

Next task is to bring in the new NAnt 0.85RC1 and NUnit 2.2 support to bring everything up to date.

Automated Builds and Assembly Versions

We had implemented a workable solution to the problem of stamping assemblies with the Cruise Control build number using NAnt when we found this which finishes the job.  Very elegant.

XSL understood (almost)

NUnit 2.2 and NAnt

Dr Neil on CruiseControl.NET

Dr Neil has provided some excellent feedback on the CruiseControl.NET article. As a result I've added a new bit about what happens when you get a stranded ss.exe instance (lots of remoting errors when you next run cc.exe).

Unfortunately I wasn't able to shed any light on how to get NAnt to work with NUnit v2.2. I tried to rebuild NAnt linking to the NUnit v2.2 assemblies but there appear to have been a whole lot of changes under the NUnit hood.

Anyone got any ideas?

testingReflections.com