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.
