Well, Stephen Forte and I pulled off the Oracle/SQL Server Interoperate session today. The crowd wasn’t huge, but they were definitely into it – the questions were outstanding, everyone gets the idea that there are hard choices to make in interoperability. Running three operating systems (Window XP host, VPC of Windows 2003 Server and VPC of Red Hat Fedora) isn't all roses and sunshine, either!

We’ve been handing out lots of RD Bingo cards, and signing even more (you have to get an RD on the card to sign their picture, get a line and you win)… the loot is great. I’m astounded at the number of folks here, getting a cellphone connection (or WiFi connection) is a serious challenge.

Now I get to relax for a couple of days and soak up some sessions before my SQL Server Profiler for the Developer session on Friday.

Ah yes, the panic is on... one more day before I fly down to Los Angeles on my way to Tech Ed San Diego. Naturally, every piece of hardware I own (and I own a lot) is acting up, knowing I'm about to leave town.

I'm presenting two sessions. The first one on Monday is called From Interoperability to Migration: SQL Server and Linux Databases Working Together which I'm doing as a duet with my buddy Steve Forte. The session stems from my time spent “on the dark side“ doing database work in Linux. Although most of my work is done in postgres, this session is going to show interoperability between Oracle 10g on Red Hat Fedora and SQL Server 2000 on Windows Server 2003 (hey, that's what the Microsoft folks wanted, so that's what they get).

I've had to migrate lots of applications over the years, and I see it as the worst kind of development. The problem is, the users see nothing, except the fact that stuff that used to work (on the old app) is now broken (on the new app). And the instinctual order of migration is flawed: we always start by migrating the data, then building the app. After all, you need some data to work from to build the new app. And so you build a tool to repeatedly copy the data from the old system to the new, and one day, you do the dead drop - you migrate the data one last time, and then everybody has to stop using the old app, and use the new app.

And then, inevitably, you find some nasty bug a few hours (or days) later. Now the question is, do you switch back to the old app, or have everyone wait until you fix the new one? If you go back, what about all the work done in the new one? Reverse migration anyone? Aaaugh!

The session focuses on how you can interoperate between applications via their databases, either long term or short term to facilitate migration. The key to the whole thing is SQL Server's ability to use OLE DB to speak to the Oracle database directly. The trick to migration is to move the data last - build your new .NET application to speak to SQL Server using stored procedures, and in the stored procedures you call to Oracle to retrieve the data.

This methodology avoids dead drop migration, since you move the data last. Since there's only one copy of the data, and both applications have access to it, the users can use whatever client they want. In fact, I've done migrations this way where I never cut off the old app, I just kept adding features to the new app until everyone wanted to use the new one, and then quietly turned off the old one.

The second session is SQL Server Profiler for the Developer. I presented the original version of this session waaay back in 1998, with Visual Basic 5 and SQL Server 7. The session came out of my experiences of dealing with even older versions of SQL Server and Visual Basic, and discovering how DAO and ODBC messed with my queries before sending them to the SQL Server. Middleware does stuff, and Profiler is the best way to find out what's really going on with your SQL Server.

Its my first Tech Ed as a Regional Director, so I guess I'll have to go spend some time at the RD Booth and see what craziness Scott Hanselman has come up with.