Nielsen c31.tex V4 - 07/21/2009 2:03pm Page 712 Part V Data Connectivity Server: Msg 8501, Level 16, State 3, Line 7 MSDTC on server ‘SQL2008RC0’ is unavailable. The following example demonstrates a distributed transaction between the local SQL Server and the second instance: USE Family; SET xact_abort on; BEGIN DISTRIBUTED TRANSACTION; UPDATE Person SET LastName = ‘Johnson2’ WHERE PersonID = 10; UPDATE [Noli\SQL2].Family.dbo.Person SET LastName = ‘Johnson2’ WHERE PersonID = 10; COMMIT TRANSACTION; FIGURE 31-6 Component Services includes a list of current DTC transactions. 712 www.getcoolebook.com Nielsen c31.tex V4 - 07/21/2009 2:03pm Page 713 Executing Distributed Queries 31 Rolling back a nested SQL Server local transaction rolls back all pending transactions. However, DTC uses true nested transactions, and rolling back a DTC transaction will roll back only the current transac- tion (this is different from a normal local transaction, which rolls back every pending transaction level). Monitoring distributed transactions As a separate service, Distributed Transaction Coordinator activity can be viewed from within the Windows operating system by selecting Control Panel ➪ Administrative Tools ➪ Component Services. Component Services provides both a list of current pending distributed transactions (see Figure 31-6) and an overview of DTC statistics (see Figure 31-7). FIGURE 31-7 The current and accumulated count of distributed transactions as viewed in Component Services. The statistics begin at 0 when DTC is restarted. If a distributed transaction is having difficulty, it will likely be aborted. However, if the transaction is marked ‘‘In Doubt,’’ forcibly committing, aborting, or forgetting the transaction using the context menu in Component Services may resolve the transaction. 713 www.getcoolebook.com Nielsen c31.tex V4 - 07/21/2009 2:03pm Page 714 Part V Data Connectivity Summary Enterprise data tends to involve multiple platforms and locations. SQL Server’s ability to leverage OLE DB and ODBC to perform distributed queries is a key factor in the success of many database projects, and knowing how to build distributed queries well is a necessary component in the database developer’s skill set. Major highlights from this chapter include the following: ■ Linked servers are all about security. I strongly recommend passing the user’s security context to the remote server. ■ Queries using the four-part name or OpenQuery() with linked servers are pre-configured and are a better practice than hard-coding the connection security information in a OpenDataSource() or OpenRowSet(). ■ Four-part name queries give SQL Server the choice of where the query is executed, but OpenQuery() enables you to carefully determine which part of the query is executed remotely and which part is executed locally. ■ Scripting the creation of the linked servers as a repeatable process is far better than creating them with the UI, even if you document the linked server configuration. The next chapter in this group of Data Connectivity chapters digs into ADO.NET, a standard in connecting to SQL Server from applications. 714 www.getcoolebook.com Nielsen c32.tex V4 - 07/23/2009 2:20pm Page 715 Programming with ADO.NET 3.5 IN THIS CHAPTER Understanding ADO and ADO.NET 3.5 Visual Studio 2008 usability features for ADO.NET 3.5 Building applications with ADO.NET 3.5 U nless data can be moved in and out of the database, there is no need for the database, the database administrator, or the database developer. In this chapter, the focus moves away from the database and into the application layer to examine one of the most important and useful SQL Server data access technology genealogies: the ActiveX Data Objects (ADO) family. The newest member, ADO.NET 3.5, is a suite of managed technologies capable of interacting with many relational database management systems (RDBMSs). Of course, SQL Server 2008 is a close relative to ADO.NET 3.5 in the family of Microsoft technologies. It is reasonable — and correct — to expect that they share a special relationship. As you will see, the underlying interface between ADO.NET application code and SQL Server is optimized. This chapter covers ADO and ADO.NET, with special attention given to the new concepts and features introduced in ADO.NET version 3.5. The first new bit of information to learn is that the technologies are not mutually exclusive. Both ADO and ADO.NET are available to the Visual Studio 2008 programmer. Both have a place in the programmer’s toolkit, and it will prove useful to know how ADO and ADO.NET technologies differ. This chapter compares and contrasts ADO and ADO.NET as an aid in making good development decisions. It also illuminates the fundamental shift that occurs between ADO.NET 2.0 and ADO.NET 3.5 because these sweeping changes are keys to getting the most not only from SQL Server 2008, but also from previous releases of SQL Server. This chapter provides information on the Visual Studio 2008 IDE features that aid in developing and debugging data access solutions that employ ADO and ADO.NET. There isn’t room to discuss all the similarities between Visual Studio and SQL Server Management Studio, though they are many and welcome. This chapter covers only Visual Studio’s capabilities to assist in the development of ADO and ADO.NET data access methods within applications. Readers new to Visual Studio will find much of the material in Chapter 6, ‘‘Using Management Studio,’’ and in Part 10, ‘‘Business Intelligence,’’ of interest as a good introduction to the user interface shared between SQL Server 2008 and Visual Studio 2008. 715 www.getcoolebook.com Nielsen c32.tex V4 - 07/23/2009 2:20pm Page 716 Part V Data Connectivity An Overview of ADO.NET In keeping with the Microsoft data access tradition, ADO.NET 3.5 builds on the existing data access technology base. Since the introduction of SQL Server v1.1, this tradition has shown some common threads of evolution. Each generation has made creating a connection between the application and the data easier than the last, and each has provided greater flexibility and improved features. The improve- ments have consistently moved in step with leading contemporary design goals, such as host-based computing, client/server, n-tier, service-oriented architecture (SOA), or Web Services, at any given time in the evolution. Each iteration of the data access technology has attempted to repair the problems of its predecessors in important areas, such as support for referential integrity, performance, and application stability. With each release of SQL Server, the oldest surviving data access technologies tend to be left behind as newer technologies are integrated. Only rarely are data access changes revolutionary. SQL Server 2008 is no exception. The original or ‘‘classic’’ ADO is showing its age and vulnerability. It is not supported by the SQL Native Client (SNAC or SQLNCLI). Although Microsoft documentation tends to use the awkward SQLNCLI acronym to refer to this new API, Microsoft folks (in presentations) and the user community in general are much more likely to use the SNAC acronym (pronounced like ‘‘snack’’). ADO is shipped with the Microsoft Data Access Component (MDAC) libraries. Furthermore, ADO will be able to access SQL Server 2008 databases. However, the new features of SQL Server 2008 will not be available with ADO, such as the new data types or the user-defined types. New applications should not be written with ADO. Instead, plan how applications now using ADO and the underlying Component Object Model (COM) technology will be upgraded or replaced. In a future release of SQL Server, ADO and COM will no longer be supported. This chapter describes the steps to undertake to begin preparing for that eventuality. The installed base of ADO-based applications is simply too large for ADO to change or disappear at this time or anytime soon. Certainly, the best practice is to develop new applications under the service-oriented architecture (SOA) model using ADO.NET 3.5. However, it’s still necessary to understand both ADO and previous ADO.NET technologies in addition to ADO.NET 3.5 in order to support and maintain existing applica- tions while building the next generation of applications. ADO brought unprecedented speed and flexibility in data access and data manipulation to the Win- dows development platform. Beginning with ADO and the COM-based OLEDB interfaces that ADO employs, developers acquired the ability to access heterogeneous data sources — from documents to databases — with a single consistent methodology. ADO abstracted the powerful yet complex COM components and OLEDB interfaces to a simple and friendly object model that enabled large numbers of programmers and web developers to build successful applications. ADO Even today, ADO remains a COM-based data access technology. It’s important to realize that Object Linking and Embedding components (COM-based OLEDB) have been around since the earliest days of the Microsoft Windows platform. Much has changed since that time. Most notably, the COM specifications were published, and, more recently, data access has moved away from the OS layer and into the common language runtime (CLR) space. However, much remains the same. As fast as 716 www.getcoolebook.com Nielsen c32.tex V4 - 07/23/2009 2:20pm Page 717 Programming with ADO.NET 3.5 32 the database world is changing, it took a very long time for that early vision of OLE and COM to be accepted by the developer community, and only then did it reach maturity. It is hoped that the software life cycle for .NET will not be as steep or as long and will enjoy a much longer ride at its pinnacle. While Microsoft is making assurances that the COM binary standard will be around through Vista and the next version of the Windows OS, Windows 7, the likelihood that it will begin descending into obscurity sometime thereafter is real. The movement toward XML-based data transfer is safely beyond critical mass. This leaves COM and the original ADO to play only a legacy role. As one convincing signal of that progression, with ADO.NET 3.5, Microsoft is recommending that the high-level ADO data access implementation of COM be accessed only through the ADO primary interop assembly (PIA) ( ADODB.dll). Figure 32-1 shows how this assembly exposes the unmanaged COM components into the managed .NET environment. The ADO code remains essentially ADO code, but through the PIA it will be managed by the CLR, rather than at the operating system layer. This will not mandate large changes in legacy implementations of ADO, though some changes will be necessary. Nor does it mean that current ADO implementations will be much different from before when written in .NET. It will still be necessary to specify a valid OLEDB data provider in the ADO connection string, for example, and to understand the interfaces and requirements of each of those data providers. Conversely, constructors and garbage collection, security, and runtime type checking (courtesy of the .NET Framework) come into play. FIGURE 32-1 Unmanaged ADO interfaces with the native MDAC services to access the database. ADO Unmanaged Applications OLE DB. ODBC Native MDAC Services ADO .Managed .NET Clients ADODB.DLL Primary Interop ADO.NET SQL native Client MDAC is not used SQLOLEDB Network Services Server Client (TCP/IP, named pipes, etc.) SQL Server 717 www.getcoolebook.com Nielsen c32.tex V4 - 07/23/2009 2:20pm Page 718 Part V Data Connectivity Application problems could result in operating system instability in this model. With SQL Server 2008, ADO uses the adodb.dll PIA to provide continued support for ADO application code while realizing the safety of a managed .NET Framework client. The SQL Native Client (SNAC) is optimized for SQL Server access because it communicates directly through the Network services. Migrating code to ADO.NET 3.5 is the development goal. To ease the transition, use the provided pri- mary interop assembly. For example, a phased approach to upgrading applications to ADO.NET can be pursued. A reasonable scenario is to first migrate ADO applications to the adodb.dll, requiring min- imal code changes. Applications gradually become modified to move state away from the database and into .NET data sets or XML streams. Once state is possible at the client, the door is open for caching and data maintenance at the client, as well as disconnected service-oriented architectures. The result is more reliable applications. Thoughtful planning is necessary in moving ADO applications to the .NET Frame- work. Microsoft has done a good job of making topics regarding moving from ADO to ADO.NET available on the Internet. Microsoft’s journal for developers, MSDN , published a very useful two-part article by John Papa, ‘‘Migrating from ADO to ADO.NET,’’ in July and August of 2004. These articles and many other articles from this informative and in-depth magazine are available free online at http://msdn.microsoft.com/msdnmag/default.aspx. The URL to part one of ‘‘Migrating from ADO to ADO.NET’’ is http://msdn.microsoft.com/msdnmag/ issues/04/07/DataPoints/default.aspx . The URL for part two is http://msdn.microsoft.com/ msdnmag/issues/04/08/DataPoints/default.aspx . Readers can also find very useful information about moving from ADO to ADO.NET by searching the Microsoft Developer’s Network (MSDN) online library at http://msdn.microsoft.com/en-us/library/default.asp. Finally, be sure to consult SQL Server Books Online when planning a migration from ADO to ADO.NET. The Books Online article ‘‘Updating an Application to SQL Native Client from MDAC’’ lists many poten- tial problems that can be avoided if identified early in the migration design. If you have an application that is already using SQL Server 2005, then the article ‘‘Updating an Application to SQL Server 2008 Native Client from SQL Server 2005 Native Client’’ will be very useful because it describes differences in behavior between the SQL Server 2008 Native Client and earlier versions of the SQL Server Native Client. Since ADO’s introduction, it hasn’t been necessary to be an advanced COM or OLEDB programmer to support, maintain, and enhance existing ADO-based applications. It will continue to be useful to have a high level of insight into COM and OLEDB to support and debug many ADO issues. Most ADO experi- ence and knowledge can be useful when working with ADO.NET. After all, ADO is the basis on which ADO.NET is built. Likewise, OLEDB is the foundation of ADO. Understanding OLEDB can also prove useful when working with ADO or ADO.NET. OLEDB The key to OLEDB is found in the consumer and provider metaphor used to describe the technology. OLEDB is a method for connecting data from data providers to applications that consume the data. Well-defined steps must be completed to create some common ground between the variety of data providers and the consumer. OLEDB is a COM CoType or related group of COM interfaces that is described in a discoverable hierarchy, qualified by properties and controlled by events. Generally, OLEDB tries to deliver rows and columns of data to consumers. Some providers are not well suited to such descriptions. The CoType hierarchy provides a ladder on which different types of data can ascend from unknown sources to the consumer, beginning at different rungs on the ladder yet coalescing at the point of delivery, known as the CoCreateInstance CoType. Each rung of this 718 www.getcoolebook.com Nielsen c32.tex V4 - 07/23/2009 2:20pm Page 719 Programming with ADO.NET 3.5 32 conceptual ladder can be thought of as a consumer of the rung below it, and a provider to the rung above it. These transitions are collectively known as interfaces. All interfaces inherit from the primordial IUnknown interface. This shows how the components are useful and reusable in that each CoType is similar in form even if very different in function. This is easily borne out if the structural similarities among the ADO objects are considered. At the simplest level, each has properties and methods, and participates in a member hierarchy. Readers desiring more details on CoTypes and OLEDB in general might want to consult ‘‘Introduction to OLEDB Programming,’’ located in the MSDN library at http://msdn.microsoft.com/en-us/library/ms714272(VS.85).aspx. CoTypes are discussed throughout this multi-chapter conceptual reference. The number of OLEDB CoTypes is fairly large. What is useful and quite powerful in OLEDB is the ability to express and transfer all provided data to the consumer in the simple terms of a data value, its length, and distinguishing properties such as a status. Ideally, the status is good data ( DBPROPSTATUS_OK), but the status may also indicate a null value or that the value is bad and by what criteria it is deemed bad among other states. OLEDB, as with all of the COM components, is not programming language dependent. This makes it an ideal low-level architecture for the high-level languages that are used to implement ADO. The low- level specifications are able to remain the same while the ADO object model can be expressed in VB, C#, scripting languages such as VBScript and JScript, and languages capable of entering the low-level specification space, such as C++. OLEDB is a rich programming solution designed to enable database technology to handle data from database and non-database sources in record sets or streams. ADO makes OLEDB available and useful to developers in a way that makes meeting those overarching deadlines and delivery schedules possible. That said, it is not the final data access solution. ADODB primary interop assembly COM and .NET are compatible technologies. .NET assemblies can be used in COM application code, and COM components can be used in .NET code. .NET assemblies can be marshaled by COM wrap- pers. The COM wrapper must implement the core set of COM interop assemblies. An interop assembly is essentially metadata — or type definitions — for the COM components expressed in managed code. For additional details on the interoperability of COM and .NET components, see the Microsoft Patterns and Practices white paper ‘‘Microsoft .NET/COM Migration and Interoperability’’ at http://msdn.microsoft.com/en-us/library/ms978506.aspx. A primary interop assembly (PIA) is designated by the original owner of a COM object. The PIA is the recommended interop assembly to be used in the .NET Framework when exposing a COM object in managed code. Microsoft provides such a digitally signed PIA for ADO in Visual Studio .NET: adodb.dll. Microsoft recommends that only this assembly be used for ADO when used in .NET code. As shown in Figure 32-2, the reference for the adodb primary interop assembly is selected from the list of .NET references when adding to a Visual Studio project, rather than adding a reference to the ADO component on the COM tab of the Add Reference dialog. One final consideration when using ADO in Visual Studio 2008 and with ADO.NET 3.5 is that the SNAC does not provide ADO support. This means that the ADO application will rely on MDAC com- ponents to access SQL Server. ADO.NET is supported in the SNAC and shouldn’t require coordination with the complex web of MDAC libraries and components. 719 www.getcoolebook.com Nielsen c32.tex V4 - 07/23/2009 2:20pm Page 720 Part V Data Connectivity FIGURE 32-2 Selecting the adodb.dll as a .NET reference in a Visual Studio project MDAC is becoming a part of the various Microsoft operating systems and will no longer be versioned or released apart from the operating systems. A specially installed MDAC is not used in any of the examples in this chapter. The MDAC drivers used are those provided with Windows XP SP2, Windows XP x64, Windows Server 2003 R2 Standard, and Windows Server 2003 R2 Enterprise x64 editions. It is unlikely that Microsoft will announce any future versioned releases to the MDAC libraries. Perhaps the best place to monitor MDAC changes in the future will be in OS releases, service packs, and patch documentation. Similarly, MDAC version compatibility should be verified through regression testing whenever a Microsoft-provided change is applied to the operating system. SNAC is a completely separate API from MDAC. The SNAC is designed to simplify the task of keeping SQL Server clients updated in lock-step with the server. When SQL clients must rely on MDAC components, an update to MDAC is necessary to ensure client and database compatibility; otherwise, problems and failures for other application components running on the client can arise. It follows that MDAC changes that are necessary for other application components can create problems with the SQL Server connectivity. With SNAC, the SQL client is contained in a single . dll file. The risks of introducing a SNAC change to the application server are low compared to the risks of introducing an MDAC change. Another place to watch for changes to MDAC and SNAC is the Data Access and Storage Developer Center at http://msdn.microsoft.com/en-us/data/default.aspx.One informative document that can be found there is the current Microsoft ‘‘Data Access Technologies Road Map’’ vision at http://msdn.microsoft.com/en-us/library/ms810810.aspx. The ADO object model Thus far, this chapter has provided a handle on ADO’s place in the .NET world and ADO’s OLEDB infrastructure, as well as how to implement ADO in the .NET Framework. Now consider where ADO fits — or more appropriately doesn’t fit — into the ADO.NET grand scheme. One of the design goals 720 www.getcoolebook.com Nielsen c32.tex V4 - 07/23/2009 2:20pm Page 721 Programming with ADO.NET 3.5 32 of ADO.NET has been to provide all the capabilities of good old ADO. At a minimum, ADO is the role model for ADO.NET. ADO.NET 1.x came up a bit short in meeting the design features of ADO, so the adoption of .NET was impeded in the data access space. With the ADO.NET 3.5 release and SQL Server 2008, the full feature set of ADO is combined with the independence and safety of the .NET Framework and the promise of XML. Not that there isn’t some work to be done before ADO is completely bested by the new kid, especially in terms of performance. Understanding this progression from ADO to ADO.NET 3.5 is best accomplished by comparing the object models of the two. To adequately complete the comparison, consider the features and compo- nents of the ADO object model. This will build a foundation for reviewing what is new and what is improved in ADO.NET as the chapter progresses. ADO isn’t just a wrapper over OLEDB. It provides real value to the developer and has several advantages over previous database access methods. The following list describes those advantages originated by ADO: ■ Independently created objects: With ADO it is no longer necessary to thread through a hierarchy of objects. The developer creates only the objects needed, thus reducing memory requirements while increasing application speed and decreasing the lines of code needed. ■ Batch updating: Instead of sending one change to the server, they can be collected in local memory and sent at one time. Using this feature improves application performance (because the data provider can perform the update in the background) and reduces network load. ■ Stored procedures: These procedures reside on the server as part of the database manager. They are used to perform specific tasks on the data set. ADO uses stored procedures with in/out parameters and return values. ■ Multiple cursor types: Cursors point to the data currently in play and can be manifested as client-side cursors and server-side cursors. It’s important to distinguish between application code cursors and T-SQL cursors. Client- side application cursors have little of the performance and contention issues of T-SQL cur- sors. Server-side cursors, particularly when updateable, can negatively affect the database almost to the degree that T-SQL cursors can be problematic. See Chapter 22, ‘‘Kill the Cursor!’’ for more information on cursors. ■ Returned row limits: This enables information retrieval limited to the amount of data actually needed to meet the user’s request. ■ Multiple record-set objects: Works with multiple record sets returned by stored procedures or batch processing. ■ Free threaded objects: This feature enhances web server performance by enabling the server to perform multiple tasks. Like all OLEDB components, ADO uses COM. ADO provides a dual interface: a program ID of ADODB for local operations and a program ID of ADOR for remote operations. The ADO library itself is free- threaded, even though the registry shows it as using the apartment-threaded model. The thread safety of ADO depends on the OLEDB provider that is used. In other words, if a Microsoft provider such as the Open Database Connectivity (ODBC) OLEDB provider is used, then no problems should be expected. If a third-party OLEDB provider is used, then it may be necessary to check the vendor’s documentation before assuming that ADO is thread-safe (a requirement for using ADO over an Internet or intranet con- nection). 721 www.getcoolebook.com . an Application to SQL Server 2008 Native Client from SQL Server 2005 Native Client’’ will be very useful because it describes differences in behavior between the SQL Server 2008 Native Client. shipped with the Microsoft Data Access Component (MDAC) libraries. Furthermore, ADO will be able to access SQL Server 2008 databases. However, the new features of SQL Server 2008 will not be available. Interop ADO.NET SQL native Client MDAC is not used SQLOLEDB Network Services Server Client (TCP/IP, named pipes, etc.) SQL Server 717 www.getcoolebook.com Nielsen c32.tex V4 - 07/23/2009 2:20pm Page 718 Part