I've been "a database guy" for quite a while. Way back in 1989, I left the security and blandness of Boeing for a new project a Microrim (of R:Base fame), which was building a new database solution (by "solution", I mean the whole shebang - server, UI, connectors to other databases, UI abstraction to run both on (hold on) OS2 and Mac).

As part of that job, I wrote the Query By Example part of the database front end (what we called a "surface"). If you've ever used Access or SQL enterprise manager, you've used QBE - you just get a table to fill in, and the system generates the SQL query under the covers for you. It's an interesting problem - it's fairly easy to represent everything from a QBE table as SQL, but going the other way is more problematic - there are some queries that just don't represent themselves well, even before you get to degenerate cases and inner joins.

Along the way I learned a fair bit about database design, normalization, and how to think like a database engine. This carried on to my later jobs, where I often chose a database as the best way to store information, and therefore I wrote a fair bit of data access code. As I moved into the object-oriented world, I wrote a fair number of what I'll call "class adapters" - classes whose purpose is to adapt between the database view of the world (rows and columns, with separate statements to query, update, or delete information) to the object-oriented world (classes with fields and methods to perform operations).

These classes aren't hard to write, but they are a bit tedious. How many times can you write something like:

m_name = (string) currentRow[NAME_COLUMN].Value;

or deal with the fact that string values in insert statements are quoted, but integers are not, without getting tired of it?

When Ado.net came out, I played around with it (not being a developer at the time, I didn't really use it). It does some neat things - strongly typed datasets, for example, but after using it for a few projects, I decided that it was a pretty big stick for the kind of stuff that I was doing. I didn't need disconnected datasets, I rarely (if ever) have written an editable grid, and I didn't like having to regenerate datasets every time I modified my schema. I also had a hard time keep track of all the pieces - queries, adapters, connections, transmissions, valves, condensors, centrifugal clutches, ultrasonic cleaners, etc.

So, I switched back to the tried and true:

execute query
while (result has rows)
    process rows

style of programming, but I wasn't fully happy with it. There was still - to use the terms Anders uses - a big "impedence mismatch" between the programming language world and the database world. There's a lot of improvement to be had, if a solution to the problem can be found.

A couple of years ago, the C# language design team started talking about whether there was something that could be done at a language level, and I got to participate in that discussion for around 9 months. The coolest part of the plans are that...

Well, I can't really tell you. Partly because I'm not the person to talk about the details, but mostly because I've been away from the language design team for nearly a year now, so I'm not sure where the discussions led.

But I know who can tell you. The members of the team will be speaking about what may be in store for C# 3.0 at the PDC.

If you can't make it to the PDC, I'll try to link to documents as they become available, or you could just wait for Luca to post them