Hướng dẫn học Microsoft SQL Server 2008 part 76 pot

Nielsen c32.tex V4 - 07/23/2009 2:20pm Page 715Programming 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 Buildi

Trang 1

Nielsen c31.tex V4 - 07/21/2009 2:03pm Page 712

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

Trang 2

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 transactransac-tion, which rolls back every pending transactransac-tion 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

Trang 3

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 orOpenQuery()with linked servers are pre-configured and are a better practice than hard-coding the connection security information in a OpenDataSource()orOpenRowSet()

■ 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

Trang 4

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

Unless 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.

Trang 5

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 applicaapplica-tions

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

Trang 6

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

Trang 7

Application problems could result in operating system instability in this model With SQL Server 2008,

ADO uses theadodb.dllPIA 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 theadodb.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 theCoCreateInstanceCoType Each rung of this

Trang 8

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

IUnknowninterface 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 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 theadodbprimary 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

Trang 9

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 dllfile 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

Trang 10

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 ofADODB

for local operations and a program ID ofADORfor 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)

Định dạng
Số trang	10
Dung lượng	1,14 MB