Richard Campbell Blogs Too

I'm not a huge Wiki fan, but Microsoft putting software into the Open Source domain is pretty cool.

If you've never heard of Wikis, you're not alone, they're kind of a weird concept (and product), a web site that's fully editable by virtually anyone, so that you get this sort of disorganized amorphous blob of potentially useful information that keeps moving and changing... wow, its just like the Internet!

Anyway, Wikis were invented by Ward Cunningham, a terribly clever fellow who now works at Microsoft (which is, after all, the land of terribly clever people). FlexWiki was developed by David Ornstein, a Program Manager for Longhorn. Do these two facts have any relation? I dunno.

This is the third time Microsoft has posted software to SourceForge, the first, back in March of 2004 was the Windows Install XML (WiX) toolset. Second is the Windows Template Library, released in May. Both these projects are libraries, and so not of any interest to regular mortals, however, they are some of the most popular projects on SourceForge, with 103,000 and 22,000 downloads respectively - the page view counts are huge!

FlexWiki, as with WiX and WTL are released under the Common Public Licence and part of Microsoft's Shared Source Initiative.

FlexWiki represents the closest thing to a product released into the wilds of Open Source by Microsoft. It'll be interesting to see what comes next.

Back in March, I was in Kuala Lumpur with my friend Adam Cogan, doing a Business Intelligence workshop.

At the time, I grabbed a Motorola MPx200 cell phone. Pretty much all phones in KL are unlocked, so you can buy a phone and plug your own GSM chip into it, and off you go.

I use Rogers for my cell phone service, and they offer both CDMA and GSM service, so when I got home, I switched my cell number to GSM and got the chip, plugged it into the phone, and off I went. And it did work - for phone calls at least.

The MPx200 runs Windows Mobile 2002 as its operating system, and includes a version of Internet Explorer and even MSN messenger. And, of course, Solitaire. But I couldn't get the web stuff working - I talked to Rogers, and I was honest with them, telling them that I wasn't running one of their phones. They were all enthusiastic about what I was attempting, wanted to know about the phone... in the end I couldn't get the stuff to work, and I only have so many cycles for fighting with such things, so I let it go.

Recently, I managed to get the phone upgraded to Windows Mobile 2003 - its not officially released by Motorola, although it is coming with their new MPx220. But a DNR listener happened to have a copy, so I grabbed it and, willingly risking my phone, upgraded it. It worked great, and now I have TWO games on my phone... Jawbreaker AND Solitaire. And the battery life is substantially improved.

Feeling all inspired, I called Rogers again this weekend, prepared to commit a good hour to being on hold, being switched from person-to-person, etc, and being told “Now you understand we can't guarantee this will work...“ It took three different people to reconfigure my account and get the right set of settings into the phone, but in the end, it worked! The trick is to make clear that the phone has more in common with the Treo 600 than any Motorola cell phone that Rogers handles. A proper data account and the detailed internet settings is all it took to make the thing fly.

So my thanks to Rogers for helping me out, the geek potential of my cell phone took a nice leap upward... what could be more fun than writing MSN messages with a telephone keypad?

Had a great time last night at the VANTUG General Meeting. Excellent turn out too - almost every seat was filled.

I demonstrated Microsoft Operations Manager 2005. This is a very cool technology for those of us who are responsible for the care and feeding of a bunch of servers. MOM 2005 is part of Microsoft System Center, which also includes Systems Management Server. And Microsoft System Center is a key player in the Dynamic Systems Initiative (DSI), one of Microsoft's three major initiatives (along with Trustworthy Computing and the .NET Platform).

The Dynamic Systems Initiative focuses on making all aspects of software and hardware manageable. At the software level that means building applications with management in mind - the most obvious thing putting Windows Management Instrumentation (WMI) points throughout your application. Software like SQL Server and Exchange report a steady stream of WMI data points to anyone listening. Think of it as SNMP on steroids. And MOM is all about consuming WMI data.

You can instrument your own applications in .NET from the System.Management namespaces, creating your own custom events, performance counters, and so on. Its not a simple thing to do, but if you're serious about being an application that can be maintained and used in the long term, its worth the effort. Log files are not enough any more, you want to work and play in the DSI world.

Ultimately, doing DSI properly means spending less money and time on keeping servers operational. Its a worthy goal, but like all of Microsoft's major initiatives, its not going to happen overnight: its a combination of new software, new thinking and new work. A couple of years from now, we'll look back on the way we manage systems today the same way we look at email pre-Internet.

Besides having fun with MOM 2005, I showed off the new error handling abilities of SQL Server 2005, essentially doing an abbreviated version of my T-SQL Error Handling in SQL Server 2005 session from Tech Ed Malaysia.

After that, it was all about toys. Here's the goodies I showed off:

• Infrared thermometer (the ultimate in civilian hortosecond generation)
• Datastor Pro 7200rpm USB2 hard drive
• Pretec 1GB Micro USB Key
• Motorola MPx200 cell phone
• WiFi Detector
• And one other goodie that shall continue to remain nameless...

Unfortunately, we didn't get to talking about my home server rig, but I'm sure I'll get a chance in the next month or so to talk about the trials and tribulations of keeping a half dozen servers happy and healthy at home.

I'm finally back home from Kuala Lumpur after 22 hours of travelling. I couldn't bring myself to blog in my near hallucinatory travel state, so I've had a good night's sleep, woken up very early and am busy catching stuff up, including this.

Tech Ed Malaysia was lots of fun, the attendees were very enthusiastic and friendly. The speaker cadre was astounding, very talented folks and lots of fun to be around.

Although the hotel was in the middle of nowhere (I started calling it the “New Jersey of Kuala Lumpur”), we did manage to get into town a number of times and do some fine exploring. We ate a chinese dinner from an outdoor kitchen in an alleyway, and bought all kinds of gadgets from various shops.

Saturday was my last full day in Kuala Lumpur, and I started it out with doing DotNetRocks from my hotel room. I had brought my full audio rig with me, including the large condensor mike and digitizer. What I hadn't realized when I first packed it up is that the power supply for the digitizer does not support 220 volts, unlike my laptop power supply. Tim Huckaby lent me his power converter (thanks Tim!) but I didn't have the smarts to actually test it out in advance.

Since Kuala Lumpur is exactly twelve time zones away from New London Connecticut where Carl and the DNR studios actually are, I was doing the show Saturday morning live with them working Friday night. So I'm up and on my laptop at 7am, talking to Carl (where its 7pm). We talk about the toys and how to do the show and agree to reconvene at 8:15am for a sound check before the show starts at 9am.

By 7:30am I'm off for a shower and some breakfast. I'd wanted to talk about the Low Yat Plaza we'd found the night before, which is this incredible toy boy heaven. Kim Tripp had taken some photos of it and I wanted to blog those before the show so everyone could see this crazy place. Kim loaded the pictures on a USB key for me and I went back to my room.

I get back to my room and I can't open the door - mysteriously, the flip bar lock had set itself! I went down to the front desk to get some help, and they sent a maintenance guy up. In theory, these locks can only be unlocked when the door is closed, but the fellow was confident he could open it. Apparently it happens all the time?!?

It took him a half hour of fiddling, but he did get the door open. Then it was my turn for some stupidity. I wired up my audio rig, but the digitizer wouldn't power up. I couldn't make Tim's power converter work! Finally, I had missed set up time, the show had to start, so I had a good hour to futz around before break time when we'd have another chance to test things out. I figured I might as well dump the pictures and return Kim's USB key, she was leaving in another hour or so.

When I told Kim my woes, she produced another power converter for me to try, so I went back up to my room, new block in hand. Kim's block had European plugs on it, and the European plugs on my power adapter were too loose to hold her heavy block in place, so I had to use Tim's block as a converter to hold things together... the resulting contraption stuck the better part of a foot out of the wall, so I braced it with my chair to stop it from falling out.

So, from the wall working outward, the plug adapter (my laptop plug is coming out the top), into which Tim's converter (acting as an adapter) is plugged into, then Kim's converter, and finally the digitzer brick.

This did the trick - I was finally up and running. At the half way point in the show we took some time to test latency (ping-pong), which turned out to be brutal: apparently doing VOIP half way around the world takes six seconds. Here's what my running audio rig looked like:

So in the end, the show came off fine, with the severe lag I couldn't chat with Carl and Rory much, but just sort of blurted out how much fun I was having in KL, the toys to talk about and the contest. As soon as the contest was under way I disconnected and ran to return Kim's power block to her before she had to leave.

With Kim gone, Goksin, Malek, Adam, Brian and I were free to do some serious toy shopping. We headed first to Central Market, picking up T-shirts, jewelry and other odds and ends. Brian and Adam cut out early, Brian had to head to the airport by 6pm, and Adam wanted to show Brian his tool before he left. So the three remaining shoppers headed back to the Low Yat Plaza to really check out the toys. Our mission - to get gigged.

Malek, Goksin and I all wanted gigabyte storage bits. Malek and Goksin were after 1GB SD cards, and we all wanted 1GB USB key. Kim had been gloating all week about her gigabyte scores in Singapore, having acquired a 1GB Compact Flash card AND a 1GB USB key. And to top it off, she bought a 2GB Compact Flash on our first visit to Low Yat the night before. She's the gig queen, and we wanted to at least be in the club.

We started at the very top level of the mall and worked downward, and it didn't take long to find this tiny Pretek 1GB USB drive. I started calling it “The gigabyte you can fit up your nose.“ Unfortunately, we were in a show room and they had none to sell! Supposedly there was a store on the lower levels had had them, so we headed there. Along the way we did find two 1GB SD cards, so Malek and Goksin were in the gig club for sure.

When we finally found the Pretek dealer, he had only ONE of the little drives. Very annoying, but we bought it anyway. Then we went back up to the top floor to complain. The fellow there was nice enough to call around to the other shops in the mall and found one more little drive, so I got one as well. So we three boys are all in the gig club, although Queen Kim leads the way as usual.

Speaking of Queen Kim, as we were wrapping up our toy feeding frenzy, Kim phones from Singapore! She's holding in her hands the Canon 20D digital SLR, and wants to confer with the ToyBoy on pricing... she figured the price converted to about $1675 US... I told her to buy buy buy! The camera isn't even available in the US yet, I believe its going to be released Oct 15th, and the best pre-order street price I've found is $1500... a $175 premium is worth it to be first!

Ultimately, I don't know if she actually bought the camera, I hope she did, I'm sure I'll hear about it soon enough.

After shopping we ate dinner at a Japanese buffet, then headed back to the hotel - Malek had a ride to the airport for 11pm. Enough time for a couple of quick beers before he was gone.

The next morning Goksin and I got up early and had breakfast together. Goksin left at 6am, I left at 7am. I called Goksin when I was ticketed and through customs at the airport, poor Malek was still there. Apparently Emiriates airlines had botched his reservation and left him for dead. Goksin, in the finest tradition of the Anti-Suckiness club, got a ticket for his buddy to get him as far as London, I'm sure he'll get himself the rest of the way home from there with a fine tale to tell. The three of us had a cup of tea together in the airport before dispersing for our various gates for home.

This session is one of my favorite “grab-bag” type sessions, and judging by the reaction of the attendees, one of their favorites too. I've never been mobbed with USB keys at the end of a session before. For those of you who didn't grab the code immediately off of me after the session, or from Tech Ed's COMM Net, I'm including it here as well.

In the session I explored essentially four areas of querying techniques. To some degree, they built on each other.

Initially I explored subquerying, an area lots of people dabble in, but haven't really hammered out all the details on. My personal favorite of the subquery examples is a duplicate detection query. In the real world, duplicate data gets entered, and we have to go clean it up. This query returns rows for every duplicate product, showing the oldest ID as the “real” one as well as the duplicate. You can adapt this query to clean up your database, transferring any foreign key rows to the oldest ID, etc.

SELECT Product_ID, Product_Name, Price,
 (SELECT MIN(Product_ID) FROM Products AS P1
  WHERE Products.Product_Name = P1.Product_Name) AS OldID
FROM Products WHERE Product_ID NOT IN
 (SELECT MIN(Product_ID) FROM Products AS P2
  WHERE Products.Product_Name = P2.Product_Name)

This version of the query show both a correlated subquery in the SELECT clause and the WHERE clause, as well as doing that one trick that subqueries are so good at - finding exceptions. The NOT IN statement says “give me only those rows that are not one of the minimum IDs for that product name.“

While I'm not going to go through every technique in the session, attached is the sample code for all of the techniques, including the very popular Rozenshtein cross-tab technique - both static and dynamic.

Advanced Querying.zip (42.34 KB)

This is one of those “I always wanted to write this” sessions about a bit of software I think not enough people know about - the SQL Server Profiler.

Profiler is your friend - it shows you what arrives at SQL Server from your application. And, believe it or not, what arrives there is not always what you sent. Sometimes middleware messes with your SQL.

Profiler can also help you trace down tricky things, like where deadlocks are happening. A deadlock occurs when two connections each hold one resource that the other needs to finish a transaction. Neither one will finish unless the other gives up its resource. When SQL Server detects a deadlock, it picks a loser, failing that transaction with a 1205 error. The other connection can then complete its transaction.

Obviously, the best way to avoid deadlocks is to not ever do that - always lock resources in the same order. I make a list of the sequence in which I'll modify tables and then always write my stored procedures to do updates in that sequence. That way, stored procedures can block each other, but not deadlock. However, this still doesn't get rid of all deadlocks.

And the problem is, the error you get for deadlocks is a bit vague - the error message returns what the competing SPID was, which would typically indicate the other computer who's transaction succeeded, but not what table was involved in the deadlock. In the session (and included in the attachment for this blog entry) is the sample code to show a deadlock in Profiler and then you can use the Object ID information around the deadlock to query sysobjects and find what table/resource was involved in the deadlock.

Also in the sample are some queries for testing out the Index Tuning Wizard, part of the Profiler and a tool that will look at the queries in a Profiler Trace file and decide if any new indexes would benefit performance. It'll also recommend removing indexes that aren't ever used.

Finally, there's my little VB6 sample app that's good for playing with ADO 2.x to see how OLE DB can mess with your SQL - in the session I demonstrated how OLE DB actually converts your SQL statement into a cursor to fulfill your request for a modifyable server-side recordset.

Last night we went out into the streets of Kuala Lumpur and found the ultimate toyboy mall - six floors of toys!

Going up the escalator, you're looking into the center of the mall, its a big cylinder, six floors high, geek stores all the way around.

Looking back down, its all cell phone shops, PC hardware, gadgets, toys, you name it...

How many malls do you know have huge billboard signs for hard drives?

This is the same session I did at Tech Ed San Diego with my buddy Steve Forte... unfortunately, Steve had a problem with his flights that meant he had to leave before the session actually started, making my duet more of a solo...

Steve and I have been doing duets for years, so I dragged a couple of photos out that we had used in the past for duet sessions...

This picture was taken around 1998 at the Papendal facility near Arnhem in the Netherlands, Steve (looks awfully young, doesn't he?) and I are working on our first joint session called “XML for N-Tier”.

This photo was taken at a costume party on Halloween of 2000 in Phoenix, Steve and I are dressed as the three musketeers, our third (Tom Howe) is taking the picture.

The interoperability session focuses on how you can use SQL Server to interoperate with other databases, in this case its Oracle 10g running on Red Hat Linux Fedora Core 1. The idea was to run two Virtual PC sessions, one with Windows 2003 and SQL Server 2000, the other Red Hat and Oracle 10g.

I used Werner Puschitz's step-by-step instructions to Installing Oracle 10g on Red Hat. Even then, its tricky, lots of places to go wrong. And since I'm running Linux from a Virtual PC session, part of the challenge is getting Red Hat happy in a VPC environment. Networking is also tough - I didn't want to use fixed IPs on the VPCs, since that would cause other network problems when plugged into various conference networks. Each VPC session grabs a dynamic IP, but the way Oracle is configured, you have to alter a listener file to tell Oracle what IP you're now running under.

On the SQL Server side of things, you need to install the Oracle tools to get Net Manager, which provides communication to Oracle from the Windows 2003 environment. That's another point where you have to specify the IP address of the Oracle server.

In SQL Server itself, the key to making the connection is linked servers - and the easiest way is using sp_addlinkedserver and sp_addlinkedsrvlogin stored procedures to establish the connection. The parameters look like this:

sp_addlinkedserver @server = 'OrclDB', @srvproduct = 'Oracle', @provider = 'MSDAORA', @datasrc = 'larryserv'

• @server is the name you want to refer to the linked server with.
• @srvproduct is the name of the database you're linking to. SQL Server checks this name carefully, if you misspelled Oracle, it won't work.
• @provider is the name of the OLE DB provider to use, in this case its the Microsoft Oracle provider.
• @datasrc is the name of the Oracle database from Net Manager.

sp_addlinkedsrvlogin @server = 'OrclDB', @useself = false, @locallogin = 'sa', @rmtuser = 'scott', @rmtpassword = 'tiger'

• @server is the name of the linked server as specified in sp_addlinkedserver.
• @useself is a flag to tell SQL Server to use the account currently logged into SQL Server on the remote server. Setting this to false means that the login will use the remote user and password supplied.
• @locallogin is the name of the account that this login can be used by. You can set it to NULL and it works with all accounts. The account can be a SQL login or a Windows login.
• @rmtuser is the user name to log into the remote server with.
• @rmtpassword is the password to log into the remote server with.

Once the linked server is established, you can do queries like this:

select * from OrclDB..SYSTEM.TBLCONTACTS where lastname = 'Campbell'

You can see the only unusual aspect of this query is the table notation, indicating the linked server and the schema that the table is associated with. With Oracle, table names are case sensitive, so you have to get the case right.

In the session we discuss not only how to interoperate, but also how to migrate. The key to migration is to move the data last, not first. Build a .NET application that calls SQL Server stored procedures, and use the stored procedures to make the calls through to Oracle. That way you can build your new client without turning off the old client, and the two clients can run side-by-side for as long as necessary. Eventually, everyone will be using the new client since its getting all the new features.

You can start adding tables to SQL Server to add new features, linked servers will allow you to do joining between the two databases if you like. Eventually, when no one is using the old client any more, you can shut it down and begin moving tables from Oracle to SQL Server. You don't have to do them all at once, just move the tables as you have time, altering the stored procedures to point to SQL tables, rather than the linked Oracle tables. Ultimately, all the tables will be moved and you can shut down the remote connection.

On the other hand, you might discover that there's stuff in Oracle you can't do without, and you can maintain this level of interoperability indefinitely.

The session went very well, unfortunately its tough to give out as a demo, since everything is in VPC images... the Oracle/Red Hat image is nearly six gigabytes!

My first session at Tech Ed Malaysia focused on the new error handling features of T-SQL in SQL Server 2005.

Although its a cool session, I have to wonder about the practicalities of doing error handling SQL Server, after all, as a server application, its usually our job to receive requests from clients and then report back on the results of the request, whether they're happy noises or error messages. And I see error handling as the ability to actually handle an error - as in, detect it, fix the problem and retry the previously error-causing SQL statement. So when would you ever do this?

The only logical place I can think of is deadlocking. Deadlocking is an artifact of SQL Server, not clients... okay, granted, a poorly written client can generate lots of deadlocks, but no client ever sends the request “can I have a deadlock please”... although for some clients its a pretty close thing.

Deadlocks, for those out there new to the concepts, are not blocking, which is where one SQL statement has to wait while another finishes its business. A deadlock occurs when one connection has a lock and requires another lock, and another connection has the other lock and requires the one held by the first connection. Its unresolvable, so SQL Server detects it, and then picks a loser, who's transaction fails... the winner goes on to complete their transaction with no awareness of the suffering spread.

With SQL Server 2005, we can actual handle deadlocks - recover from them transparently so that the client applications don't even know they're happening. Now that doesn't mean that we shouldn't continue to avoid deadlocks in the first place. The best way is to avoid the scenario I just described: make sure all clients lock resources in the same order, so that they block each other, rather than deadlock. Blocks will naturally resolve on their own (or else timeout). Deadlocks are uglier. Stored procedures can help by making sure that clients can't grab data themselves, they have to go through stored procedures. And then you have rules for writing stored procedures, so that the same tables are modified in the same order in every procedure. As long as you make certain you're locking in the same order, you'll block rather than deadlock.

But even with those efforts, you'll still get the occasional deadlock, as transactional velocities rise and queries take longer and longer to run. That's where this clever bit of code comes in:

CREATE PROCEDURE DeadLock_Test AS

SET NOCOUNT ON
SET XACT_ABORT ON
SET DEADLOCK_PRIORITY LOW

DECLARE @Err INTEGER
DECLARE @ErrMsg VARCHAR(200)

RETRY:
BEGIN TRY
  BEGIN TRANSACTION
  UPDATE tblContact SET LastName = 'SP_LastName_1' WHERE ContactID = 1
  UPDATE tblContact SET LastName = 'SP_LastName_2' WHERE ContactID = 2
  COMMIT TRANSACTION
END TRY
BEGIN CATCH
  SET @Err = @@ERROR
  IF @Err = 1205
    ROLLBACK TRANSACTION
    INSERT INTO ErrorLog (ErrID, ErrMsg) VALUES (@Err, 'Deadlock recovery attempt.')
    WAITFOR DELAY '00:00:10'
    GOTO RETRY
  IF @Err = 2627
    SET @ErrMsg = 'PK Violation.'
  IF @ErrMsg IS NULL
    SET @ErrMsg = 'Other Error.'
  INSERT INTO ErrorLog (ErrID, ErrMsg) VALUES (@Err, @ErrMsg)
END CATCH

So in this sample stored procedure, I use the new Try and Catch statements to provide error handling. The code in the Try block executes my intended update statements, in the example I'm just updating two contact rows, changing the last names. The two updates are wrapped in a transaction. If there's no problems, the transaction starts, the two rows are updated, the transaction is committed, and the stored procedure finishes.

Now, to introduce some fun, on a separate connection I do this:

BEGIN TRANSACTION
  UPDATE tblContact SET LastName = 'Direct_LastName_2' WHERE ContactID = 2

And then in another connection I execute the stored procedure. So the first connection is holding a lock on ContactID = 2, and the stored procedure has got a lock on ContactID = 1 and is waiting for the lock on ContactID = 2. Now I hop back to the first connection and execute the following:

UPDATE tblContact SET LastName = 'Direct_LastName_1' WHERE ContactID = 1

Now I've created a deadlock situation. The first connection has a lock on ContactID = 2, waiting for a lock on ContactID = 1, and the stored procedure connection has a lock on ContactID = 1 and is waiting for a lock on ContactID = 2. SQL Server detects the deadlock and chooses a loser. Since the stored procedure has its deadlock priority set low, it always loses.

When the deadlock error occurs in the stored procedure, the code in the Catch block executes. The first thing that happens is I retrieve the error code from @@ERROR and take a look at it. If its an error 1205, I know that's a deadlock, so I can do my deadlock recovery. The first step is to rollback the transaction so far. This releases the lock the stored procedure was holding on ContactID = 1, so the other connection finishes the transaction successfully. Since its finished, I can commit it, changing the last names to Direct_LastName_1 and Direct_LastName_2.

Meantime, back at the stored procedure, after rolling back the transaction, the stored procedure records the fact that it had a deadlock into an error logging table, then waits a few seconds to give the other side of the deadlock a chance to finish. Once the wait is over, the GOTO statement jumps execution back up to just above the BEGIN TRY block in the stored procedure, and the updates are attempted again. Since the other transaction is already finished, all is well, the transaction completes and the names are changed to SP_LastName_1 and SP_LastName_2. Who said being the deadlock loser sucked?

Next session - the SQL Server/Windows interop with Oracle/Linux session... supposed to be a duet with Steve Forte, but his flights got messed up and he has to leave early, so I'm doing this one solo again, just like in Montreal. Right after the interop session I'm reprising my SQL Server Profiler for the Developer session.

Wow, already half way into Tech Ed Malaysia, and I'm finally getting a blog entry done. We're having waaay too much fun.

After flying 13 hours Vancouver to Hong Kong, followed almost immediately by the three hour Hong Kong-Kuala Lumpur leg, I arrived in KL short a day... got on the plane late Thursday night, arrived the afternoon of Saturday. Those darn date lines.

It didn't take me long after arriving to find Tim Huckaby (who was good enough to leave me a message at the desk) and Goksin Bakir (he just called me on my cell phone)... we hung out at the pool and drank beer, complained about jet lag and soaked up the indominable KL heat. That night Brian Noyes join us as well for a trip across the lake to a nice Chinese dinner where they have one sneaky Peking Duck.

Sunday was the super tour day - from 7:30am to 9pm we were out and about with our guide Razali and the fabulous elephants of Kuala Gandah. Tim, Brian, Goksin, Kim and I were made volunteers of the sanctuary, rather than visitors, which gave us more access, but we had to do some work, too... here's some examples:

This is Cek Mek with our guide, Razali. One of our first stops at the sanctuary was to go out in 4x4s to feed Cek Mek... she spends most of her time away from the rest of the herd, hanging out in the jungle. She's one of the two “working” elephants, who are actually used to assist the team in moving wild elephants. The other working elephant is Cek Bunga, who doesn't like people all that much, so we didn't get anywhere near her.

Back at the sanctuary proper, we got into the main compound to visit with more elephants, some big:

...and not so big...

We also got to visit with Lasha, a 2.5 year old male who has been fighting intestinal parasites. He's very weak and thin, so he's being kept from the rest of the herd for his own safety. We went into an area behind the compound to visit with him and give him some goodies to eat.

Kim was especially fond of him...

Later, Kim and Brian brought Lasha out from the holding area in the back to the main area for feeding.

As volunteers, we helped visitors feed the elephants... there is a technique and some safety tips involved!

Later in the afternoon Razali took us on a hike through the jungle, to a little village... maybe a dozen people lived there total, the patriarch of the family is a master blow-darter. He put on a fine display firing a foot long dart into a banana tree a good fifty feet away... after a couple of tries, anyway.

Then Goksin took a shot at it... apparently Goksin is a blowdart shark, nailing the tree on the first shot!

After that, we weren't allowed to play with the blowgun any more. We hiked back to the village. Along the way Razali pointed out and offered up some food from the jungle, including heart of palm and water from a vine.

Between the five of us, we took about 400 pictures, I'll put together a full storyboard one of these days.

So that was Sunday - after returning to the hotel we headed down to the bar and consolidated pictures, plus Steve Forte showed up. We made plans for the next day, taking a tour of the Batu Caves and other religious sites. Kim had to do a pre-conference seminar the whole day, she's still annoyed with us for having fun while she had to work.

This is the entrance to the Batu Caves, all 272 steps of it.

Did I mention there were monkeys (long-tailed macaques, to be exact) everywhere? These are the rats of the monkey world, stealing off of anybody who is slow enough to snag. We saw monkeys running off with bags of peanuts, ice cream bars, you name it. One little bugger grabbed my water bottle, I shook him off, and as he prepared to give another go, I flipped the bottle around and gave him a face full. Yeah yeah, I'm fighting with a monkey, but hey, he started it!

The Batu Caves are ancient limestone, filled with Hindu shrines. And they're huge!

This is the view from the top of the stairs looking into the caves, you can see the first chamber, the roof is 250 feet up. Beyond is stairs into a second open air chamber.

After taking a look at the rock formations, the shrines and the macaques scattered throughout the caves, we headed back down the many stairs and into our taxi for our next stop on the religious tour... the museum of Islamic art. However, the cab driver was a bit confused and took us instead to the National Museum of Malaysian Art... its a nice museum, full of stories of the heritage of Malaysia. But it didn't fit with our theme of all Malaysian faiths, so after a quick walk through we headed back to the cab.

On the second try the cabbie did find the Museum of Islamic Art, and also found out it was closed on Mondays. Ah well. Third stop, a Buddhist Temple. This place was open, and fabulous.

Our cabbie came with us to give us basic instruction on how to get around the temple, including proper observations of lighting some incense, and getting your fortune.

Here Steve and Brian, shoes off, are getting instructions on using the luck sticks. You pick up the sticks in a bunch, then drop them back into the bin a couple of times. Then you pick one, and match its number with a little drawer in the bin. Inside the drawer is a bit of paper with your fortune on it. Those towers with the ladder beside them are wish towers, in a different ritual you put a wish on a bit of paper and the temple staff put the wish in with one of those lights on the towers.

That was enough fun for Monday, we headed back to the hotel.

On Tuesday Steve and I headed back to the Islamic Museum of Art, which was now open... only to discover that you weren't allowed to take photos inside. However, it is an amazing place, lots of old copies of the Quran and other artifacts from the history of Islam. There was a big screen tied to a computer in one room that would read the Quran to you in Arabic, showing simultaneous English translation. Very cool. And the favorite part of the museum was the model room, full of 1/100 scale models of the major mosques around the world, including Mecca and Medina. Incredible structures, temples with room for two million people!

Tuesday afternoon was my first bit of work, a SQL Server “Ask the Experts” panel I sat on with Kim and Steve, along with Rodney Fournier (the cluster god!) and Prakash Sundaresen... Joe Yong from the SQL team showed up to field all the “When is SQL Server 2005 shipping” questions.

Its now early Wednesday morning here in Kuala Lumpur, and the real work begins. I have a session every day til the end now, two on Thursday.

I'm just a few hours away from flying off to Kuala Lumpur for Tech Ed Malaysia.

I'm flying on Cathay Pacific, not my usual airline, but their routing kicks ass: Vancouver-Hong Kong-Kuala Lumpur. I leave at 3am Friday morning (that's late, late Thursday night) and arrive around 1pm on Saturday. Its about 24 hours travel, door-to-door, I did the same trip in March for a Business Intelligence workshop.

There's a significant contingent of RDs going... Adam Cogan, Goksin Bakir, Kim Tripp, Malek Kemmou, Steve Forte and Tim Huckaby. So expect some serious speaking, and serious partying.

A bunch of us are heading out with one of my favorite Malaysians, Razali of the Utan Bara Adventure Team. We're going to spend the day with Razali, exploring Malaysian jungle and hanging with the elephants of the Kuala Gandah Elephant Center.

And then there's the actual conference. I'm doing an all SQL Server set of sessions:

• SQL Server Profiler for the Developer
• Advanced SQL Querying Techniques
• T-SQL Error Handling in SQL Server 2005

Plus Steve and I are going to do our duet session on interoperability between SQL Server on Windows 2003 Server and Oracle on Red Hat Linux.

We're staying at a place called the Palace of the Golden Horses, apparently its an amazing resort, I guess we'll find out when I get there.

Well, one night stretched into four, as usual...

After my main workstation freaked out and stuff stopped working reliably, I pulled the motherboard and had it replaced under warranty. It meant peeling all the water cooling off very carefully to extract the board without making a mess, but I got it done.

Took a couple of days to get the motherboard actually back home. Sprite got it in late Thursday night, but I didn't actually swap it til Saturday morning. Then there's always the fiddly bits of getting it mounted again, and getting the water cooling blocks cleaned up and re-installed.

Along the way I had blown the drives off, thinking that maybe the network and raid problems might be fixed with a clean install, and I'd always wanted to re-install that system in the first place, when I had done the initial installation a few months back, somehow I'd left the Hyperthreading off, which actually installs a different kernel in XP. And I never found a way to fix it, everywhere I looked they said “re-install from scratch.”

I like a scratch re-install - it feels fresh. So off I went on my happy re-install path. Unfortunately, the built-in NIC is a late generation Intel gigabit jobbie, so the XP disk doesn't recognize it, so all the network stuff has to be done post-installation after I can get the driver loaded.

Once I got the point of getting the network stuff set up, I couldn't register with my domain - the error message said the user or password was wrong. I went around in circles for a couple of hours on this one, interspersed with a little stress relieving Doom 3 when I couldn't figure out the problem (only ID has really figured out the therapeutic value of shotgun blasts).

I could surf the Internet from the machine, but I couldn't activate and I couldn't register with the domain. And the error messages were hopeless. Then I noticed the date was set to January 1, 2002. So I opened up a command window and used net time /set to grab the time from my domain servers, and everything was fine - activated and domain registered. I think kerberos is a fine idea, I just wish they'd give some hints in the error messages, “bad user name or password” doesn't cut it.

Oh, and I threw on Windows XP Service Pack 2, of course. Then I loaded a couple of SETI@Home work units to run and went to bed. In the morning, the screen was covered in white bars and I had no user interface... although SETI@Home was still doing its thing. I used my handheld infrared thermometer to check the temperature of the Matrox Parhelia... the water loop was showing 110F (remember, this is running under full load all night), the water block on the video card was at 120F, the uncooled RAM chips were at 160F. A wee bit too hot.

So I happened to have some Tweakmonster BGA RAM sinks, mix in a little Arctic Silver Thermal Adhesive, and I'm cooling video RAM.

Notice I've STILL managed to avoid breaching the water loop!

Fresh off the victory of my water cooled secondary workstation, I decided to finish off my primary workstation. The primary is the triple-screened machine running a Matrox Parhelia video card. I do my development work across its lovely 3840x1024 set of displays.

I had a couple of minor things outstanding on it to do - adding in a monitoring display for the front of the case that shows temperatures and fan speed. Of course, in this situation, I'm monitoring the temperature inside the case and in the water loop using a water loop sensor. And the fan I'm monitoring is actually a water loop impeller.

Harmless revisions, right? So off I go, fitting the bits into the case, breaching the water loop carefully and inserting the new components, and everything goes fine.

Until the motherboard (an ASUS P4C800-E) freaks out and stops working. Well, just the network adapter, and the RAID controller, and... well, I don't want the motherboard any more. Its all under warranty, but the price of building your own machines from parts is that you have to fix 'em too. So I called up my buddy Mike Neilsen at Sprite Computers (Mike supplies most of my components) and he ordered up a replacement motherboard for me.

Didn't take me long to pry the motherboard out of the case, and I managed to do it without breaching the water loop!

So I guess tomorrow I'm rebuilding my main workstation... a night without my beloved triple screen display! Horrors!