Migrating from a database we quite like to one we do not provides as much fun as surgery.

After the DBA has promoted the database into QA we find our application is spouting Primary Key violations because the sequence.nextval values are below those used within their respective tables. Identity columns. Yet another reason to prefer SQL Server. There's a clear pattern here.

Sure, there are some advantages but we'd take portability over the possibility of having more than one auto-generated sequence any day.

It's interesting catching the impressions of an Oracle expert going the other way. Oracle to SQL Server: Crossing the Great Divide, Part 2. The comments in Part 1 make for a fun read. Especially those that bemoan the developer tools. Toad's okay.

Actually, it's not especially so having spent ten days in Palo Alto this month not doing anything remotely tech-related. The next time I'm there though I'll be sure to pop by the William Gates Center in Stanford at the very least. Well, I finally got round to playing with NServiceBus but that's pretty much it.

Back in Blighty meanwhile there's been a steadily growing realisation that I much prefer SQL Server 2008 to Oracle 11g. What ought to be simple, isn't necessarily so, productivity is near zero and success is being defined in terms of not doing anything too damaging to production systems during migration. The plan is to port the Bloomberg ETL process from SQL Server to Oracle and replace the shambolic FTP interface with what seems to be a more robust web services equivalent over HTTPS. Authentication via X509 certificate. Nothing too radical.

We're talking to Oracle via ODP.NET - having known for a while that Microsoft was deprecating System.Data.OracleClient - and using the OracleXmlCommandType. For inserts and updates I lost a crazy amount of time by not using the System.Xml.XmlConvert.ToDateTime method. Oracle's quite particular about date format so "2010-04-01" is an Unparseable Date OracleException, which seems more than a little ridiculous.

Also surprised to find that there are no DATEDIFF and DATEADD functions out of the box. Luckily, they're here. Perhaps I'm used to having better developer tools. Or I need my hand to be held. Probably a bit of both. There's certainly no contest in deciding between which database I'd rather work with given the partition enhancements in SQL Server 2008. Apparently, I'm not alone with regards to views about Oracle being an obstacle.

We interviewed with a London-based Hedge Fund last Friday and, as usual, it was interesting. The first guy I saw (head of development) is a graduate of Conchango, a company that writes software of excellent quality using good developers, the latest software technology and techniques, etc. Also, they often kindly host the London Dotnet User Group meetings at their offices near London Bridge.

Naturally the interviewer asks fair questions along the lines of Value Types versus Reference Types and Garbage Collection. Inheritence and Shadowing. So far so good. Only when we get to the Messaging architecture used and extended at the previous client's site is there a little uncertainty. Without the source code, which we didn't take with us, we can't remember enough detail about the implementation from July 2008 so there's one shaky answer.

Next up is a question about our exposure to SQL Server 2005. Yup, we used it. Oh, which bits? That will be the new Try-Catch (after a little prodding about error-handling). We mention not having used CLR functions but being aware of the possibility which leads to a question about the components of the CLR... and we've a blank moment!

The JIT compiler! In fact we mentioned just JIT.

This is *all* that arrives. That's it. Nothing about Exception-Handling, Memory Management, Thread Management, Garbage Collection, Security, Managed Code, Type Safety - this is an impressive list already - Portable Executables nor IL never mind debugging and profiling services offered. Oh, there's more that wasn't mentioned. Code management (loading and execution), Application memory isolation, Access to metadata (enhanced type information) and Interop. Nice.

Then comes the first of a few quirky incidents. Hint: If ever an interviewer testing your C# knowledge offers the Base Class Library as a component of the CLR it's probably worth saying something. To prevent an already lengthy entry from growing needlessly still a summary will do here. When Interviewer #1 is replaced by a senior developer I then learn that impersonation does not work the way I've used it. Apparently, I've misundersood all along that using the identity element in the web config for an ASP.NET web application will not allow me to use credentials for a SQL Server connection. Maybe at that point I should have just looked it up on my iPhone and shown him this:

<system.web>
    <identity impersonate="true" userName="domain\username" password="password" />
</system.web>

Of course that might have seemed a bit smug. Both nice guys. Both almost certainly good developers. I'd still like to work with them on the enterprise reporting solution due by the end of the year. However, during my next interview we won't assume that the interviewers have a monopoly on .NET understanding.