UP TO THIS POINT this book has been about COM-based ADO; from this point forward it's all about the .NET Framework, ADO.NET, 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 WinForms 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. In this second half of the book, I focus strictly on my personal area of .NET expertise: data access and especially, data access with SQLServer. You might sense a bias in favor of Microsoft SQL Server (guilty) and the Sql-Client 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 namespace implements the System.Data classes in much the same way. Sure, I point out areas where there seem to be differences between the provider implementations; but no, I won't be getting into the Odbc .NET Data Provider. Because of Microsoft's hesitancy to keep this provider up to date during the beta cycle, my technical editors and I were unable to include much more than a passing reference to this provider. Check my Web site for an update sometime after this book hits the streets for differences and issues.

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 System's 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.

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. It wasn't long before it became clear that Microsoft needed something new-entirely new-in order to accomplish this goal. Visual Basic just didn't cut it when compared to the heavily object-oriented Java applications with which it was competing. Before this, each new version of VB had inherited language and user interface (UI) supported functionality features from its predecessor. Yes, each new version usually left some unworkable functionality behind, but generally, these "forgotten" features were minor-most developers learned to live without them. When designing VB .NET, however, the Microsoft development team felt that too many of these "legacy" features hobbled Visual Basic's potential by preventing, or at least complicating, easy implementation of more sophisticated features. Thus, the advent of VB .NET.

Unfortunately, as I see it, more than a few BASIC and Visual Basic developers really expect continued support for much of this "obsolete" functionality. Over the years, VB developers have learned (for better or worse) to depend on a forgiving language and an IDE that supports default properties, unstructured code, automatic instantiation, morphing datatypes, wizards, designers, drag-and-drop binding, and many more automatic or behind-the-scenes operations. More importantly, VB developers pioneered and depended on "edit and continue" development, which permitted developers to change their code after a breakpoint and continue testing with the new code. This was a radical departure from other development language interfaces and, for a decade, put Visual Basic in a class by itself.

Microsoft expects "professional" Visual Basic developers (whoever they are) to wholeheartedly embrace Microsoft's new languages-including the new "Visual Basic"-and (eventually) step away from Visual Basic as we know it today. Consider that a Visual Basic "developer" can be as sophisticated as a front-line professional who writes and supports thousands of lines of DNA code or as challenged as an elementary school student or part-time accountant creating a small application against an Access database. Some of these developers will be skilled enough and motivated enough to adapt to a new language-some will not. Some have the formal training that permits them to easily step from language-to-language-many (I would venture the majority) do not. Some professional developers, faced with this magnitude of change, will opt to find another language or another seemingly simpler occupation, such as brain surgery.