This book is all about using ADO.NET with C# (pronounced C sharp), .NET Framework, and to some extent about how Visual Studio .NET helps you build ADO.NET-based applications. The concepts and code discussed and illustrated here apply (in most cases) to .NET Windows Forms and ASP Web Services and other ADO.NET platforms.

To make the transition to .NET easier for you and to clarify how I view this new technology, I start by helping you get familiar with .NET, its new terminology, and the new ways it allows you to access your data. There are many tutorials on .NET, most of which clearly describe the technology, albeit each from a unique and distinct point of view. In this book, my intended target audience is the experienced COM-based ADO developer. I focus strictly on my personal area of .NET expertise: data access and especially, data access with SQL Server. You might sense a bias in favor of Microsoft SQL Server (guilty) and the SqlClient namespace. Perhaps that's because I've had more experience coding, designing, implementing, testing, and teaching SQL Server than any other DBMS system. Again, in most cases, the OleDb and Odbc namespaces implement the System.Data classes (Microsoft.Data classes in the case of Odbc) in much the same way.

The Odbc .NET Data Provider is not a part of the Visual Studio .NET initial release-you'll need to download it directly from Microsoft's Web site. My informal tests show that the Odbc data provider, which uses Platform Invoke (PI), is faster than the OleDb data provider, which uses COM, although it is roughly twenty percent slower than the SqlClient data provider, which uses Tabular Data Stream (TDS). I talk a little more about this later. Before you decide to close your ears to the OleDb data provider for being the tortoise of the pack, just note that at present this is the only data provider that directly supports importing good ol' ADO Recordsets.

For differences and issues, check our Web sites or the Apress Web site for updates sometime after this book hits the streets.

How We Got Here

A number of years ago, Microsoft found itself in yet another tough spot. Overnight (or so it seemed), the Internet had become far more popular than expected and Microsoft was caught without a viable development strategy for this new paradigm. Developers all over the world clamored for ways to get their existing code and skills to leverage Web technology. Even Microsoft's own internal developers wanted better tools to create cutting-edge Web content and server-side executables. These same developers also found that component object model (COM) architectures didn't work very well with or over the Internet-they were never designed to. Sun Microsystems' virtual stranglehold on Java and the ensuing fight over this language made it imperative that Microsoft come up with another way to create fast, light, language-neutral, portable, and scalable server-side executables.

Microsoft's initial solution to this challenge was to reconfigure their popular and well-known Visual Basic interpreter in an attempt to provide server-side (IIS) functionality to the tool-hungry developer community. To this end, VB Scripting Edition sprung to life, aimed at a subset of the four million Visual Basic developers trying to create logic-driven Web content for this new beast called "eCommerce."

As many of these developers discovered, an Active Server Page (ASP) created with Visual Basic Script (VBScript) was relatively clunky when compared to "real" Windows-based Visual Basic applications and components. The VBScript language was confined to the oft-maligned Variant datatypes, copious late-binding issues, and interminable recompiles. Despite these issues, a flood of Web sites were built around this technology-probably because they were (loosely) based on a form of a familiar language: Visual Basic.

Ahem! For those developers who had grown up using C and then its object layer abstraction C++ (these are the scary, awkward languages to the VB community-the ones with the curly braces {}, pointer things ->, and semicolons ;, and in the case of C++, OOP), Microsoft offered JScript-a version of ECMAScript, which from a syntactical viewpoint is closer to C++ and JavaScript than Visual Basic. There were some advantages to be gained by using JScript over VBScript in clientside code, one of which being that, in theory, many other browsers, other than just those Microsoft offered, supported JScript, thereby potentially enabling the code to be browser neutral.

However, Microsoft sought some better way to satiate the needs of millions of Visual Basic developers and their ever-growing interest in the Web without compromising performance or functionality, perhaps providing them, maybe forcing them, to a new world of OOP without the need to learn JScript (or any other curly-brace language)!

It wasn't long before it became clear that Microsoft needed something new-no less than a whole new paradigm, a landslide shift, a new reality with some old familiar concepts, some new concepts, and some borrowed or adapted concepts-in order to accomplish this goal. This was the birth of the .NET platform.

Anders Hejlsberg, a Microsoft Distinguished Engineer, crafted a brand new programming language for this new world reality. This language is C#, which fits with .NET hand in glove, horse and carriage, love and marriage, so to speak. Okay, so I like C#, but it isn't the only language that is now supported in .NET. Syntactically, C# is an OOP, curly-brace language, with semicolons, and thus a language with which C++ and Java developers will quickly feel comfortable and "at home."