分享
 
 
 

ADO.NET 2.0 Feature Matrix

王朝asp·作者佚名  2006-01-09
窄屏简体版  字體: |||超大  

ADO.NET 2.0 Feature Matrix

Bob Beauchemin

DevelopMentor

July 2004

Applies to:

Microsoft ADO.NET 2.0

Microsoft SQL Server 2005

Summary: ADO.NET 2.0 includes a new base-class provider model, features for all providers, and

changes to System.Data.SqlClient. Get an overview of these new features, examples of their use, and a

chart of which features are provider-neutral and SqlClient-specific. (14 printed pages)

Contents

The Base-Class-Based Provider Model

Connection Pooling Enhancements

Asynchronous Commands

Bulk Import

Provider Statistics

AttachDbFileName

SQL Server 2005-Specific Features in SqlClient

Conclusion

ADO.NET 2.0 comes with a plethora of new features. This includes a new base-class–based provider

model and features that all providers can take advantage of, as well as changes that are specific to

System.Data.SqlClient. Because the .NET Framework 2.0 is being released in conjunction with SQL

Server 2005, some of these features require SQL Server 2005 to be usable. This article is meant to serve

as an overview and roadmap of the new features, give examples of their use, and includes a chart of

which features are provider-neutral and which are SqlClient-specific. In future articles in this series, I'll

be going over some of the features in greater detail. In addition, there are many new features of the

DataSet and friends; these will be covered in future articles.

The Base-Class-Based Provider Model

In ADO.NET 1.0 and 1.1, provider writers implemented a series of provider-specific classes. Generic

coding was possible based on the fact that each of the classes implemented a generic interface. As an

example, System.Data.SqlClient contains the class SqlConnection and this class implements

IDbConnection. System.Data.OracleClient contains the class OracleConnection, which also

implements IDbConnection. The provider-specific classes could implement data-source–specific

properties and methods, e.g., SqlConnection implements the Database property and the

ChangeDatabase method. OracleConnection does not, because the Oracle database does not have the

concept of multiple "databases" (these are known as catalogs in ANSI SQL) per database instance. The

new provider model in ADO.NET 2.0 is based on a series of base classes in System.Data.Common.

These provide a basic implementation of common functionality and, of course, each of the base classes

implements the still-required generic interface for backward compatibility. Provider writers can choose to

use the base classes or support the interfaces.

There were two exceptions to the interface model in previous versions, the

DataAdapter/DbDataAdapter and CommandBuilder. The CommandBuilder class provides an

automatic implementation of INSERT, UPDATE, and DELETE commands that use the same column-set,

for a simple SELECT command. Extending a CommandBuilder while keeping the base algorithm that it

used to create action statements was not possible because the SqlCommandBuilder was a sealed class.

Although there is still no way to reuse the SqlCommandBuilder parameter parser, there is a

DbCommandBuilder base class in System.Data.Common. There are new features exposed at the

base-class level in these classes, too. The DataAdapter/DbDataAdapter base classes expose mechanisms

for pushing provider-specific types like SQL Server SqlTypes into the DataSet (the

ReturnProviderSpecificTypes property) and for batch updates (StatementType.Batch enumeration

value and UpdateBatchSize property). The DbCommandBuilder common base class includes a property

to indicate concurrency policy choices (the ConflictDetection property).

Provider Factories

One of the complications of the interface-based approach in ADO.NET 1.0 and 1.1 is that you can't call a

constructor on an interface. You must create a concrete instance of a specific class. Previous APIs like

OLE DB and ADO worked around this by overloading the connection string. The connection string

contained the COM PROGID of the provider, and the correct DataSource class was created based on this

PROGID. This was possible because OLE DB DataSource PROGIDs were stored in the registry.

' VB6 ADO code, Connection is an interface (actually it's _Connection)

Dim conn as Connection

' note that the default provider is MSDASQL, the OLE DB provider for ODBC

' this uses the OLE DB provider for SQL Server

conn.ConnectionString = "provider=sqloledb;.." ' other parameters

deleted

conn.Open

ADO.NET 2.0 has a solution for this. Each data provider registers a ProviderFactory class and a provider

string in the .NET machine.config. There is a base ProviderFactory class (DbProviderFactory) and a

System.Data.Common.ProviderFactories class that can return a DataTable of information about

different data providers registered in machine.config, and also retrieve the correct ProviderFactory given

the provider string (called ProviderInvariantName) or a DataRow from the DataTable. Conditional

code that used to be written like this:

enum provider {sqlserver, oracle, oledb, odbc};

// determine provider from configuration

provider prov = GetProviderFromConfigFile();

IDbConnection conn = null;

switch (prov) {

case provider.sqlserver:

conn = new SqlConnection(); break;

case provider.oracle:

conn = new OracleConnection(); break;

case provider.oledb:

conn = new OleDbConnection(); break;

case provider.odbc:

conn = new OdbcConnection(); break;

// add new providers as the application supports them

}

...can now be written like this:

// get ProviderInvariantString from configuration

string provstring = GetProviderInvariantString();

DbProviderFactory fact = DbProviderFactories.GetFactory(provstring);

IDbConnection = fact.CreateConnection();

The appearance of a standard for retrieving the data providers installed on a machine and a

ProviderFactory for each one opens up some other interesting possibilities.

Server Enumeration

The provider configuration entry in machine.config specifies a bitmask that indicates which of the base

classes or base interfaces this provider supports. This is because not all data providers need to support

all the functionality in System.Data.Common. For example, CommandBuilder is a "nice-to-have" class,

but you could do fine without it.

DbEnumerator is a new base class that has been added to the mix in ADO.NET 2.0. This class permits

data providers that support it to obtain a list of data sources. For example SqlClient supports this class

and returns a list of SQL Server instances that are available on the network. This allows programs and

tools to present the user with a choice of data source. One of the tools that use this is Visual Studio 2005.

Connection String Builder and Metadata Schemas

Visual Studio .NET used, until now, an OLE DB component to build connection strings to represent data

sources. When you use Server Explorer in Visual Studio 2005 to add a new Data Connection in Visual

Studio .NET 2003, it displays the OLE DB connection string builder, which lists the OLE DB providers

installed on your machine, not the .NET data providers. It then allows you to select a provider (albeit an

OLE DB provider) and build an ADO.NET connection string for the corresponding provider. In Visual

Studio 2005, DbProviderFactories, mentioned above, can present you with a list of .NET data providers,

and a class, DbConnectionStringBuilder, is used by a graphic user interface component to enable a

programmer to build a connection string graphically and load and store connection strings from

configuration files.

Visual Studio 2005 Server Explorer also obtains data source metadata such as lists of Tables, Columns,

Views, and Stored Procedures for display. The ANSI SQL specification has a base specification for this

metadata; it's known as the INFORMATION_SCHEMA views. These generic views are a nice start, but

sometimes need to be extended with database-specific views or information. In ADO.NET 2.0, data

providers can provide an XML-format configuration file that lists what metadata is available and how to

obtain it from the database, since all databases don't yet support the INFORMATION_SCHEMA views.

This will be a big help in permitting tool programmers to obtain a provider-defined extended set of

information. I'll be talking more about enhancements to the provider model in future articles.

Tracing

It's very useful to permit programmers and support staff to trace database API calls to find out where in

the data access stack a problem lies, given a description from a user or error message from a program.

In general the problem can arise from:

1. Schema mismatch between client program and database reality

2. Database unavailability or network library problems

3. Incorrect SQL, either hard-coded or generated by an application

4. Incorrect programming logic

In the past, instrumenting code to permit tracing has been left up to the individual provider writer,

although there are some de facto standards in some APIs, such as ODBC. The lack of a standard OLE DB

trace made it more difficult to resolve OLE DB and ADO problems. Although this is not an ADO.NET-only

architecture, Microsoft providers in ADO.NET 2.0 take advantage of generalized tracing and

instrumentation APIs. Using the new functionality, you'll be able to trace a problem at any level of the

application stack. Not only are Microsoft ADO.NET providers instrumented, but other parts of the data

access stack use this functionality and it's available for provider writers to implement as well. Even the

ADO.NET 2.0 DataSet and related classes have built-in diagnostics. I'll cover tracing in depth in a future

article.

SqlClient Enhancements

The Microsoft flagship database is SQL Server and SqlClient is the SQL Server-specific provider. ADO.NET

2.0 actually ships with four Microsoft providers:

1. SqlClient—the Microsoft provider for SQL Server

2. OracleClient—the Microsoft provider for the Oracle database

3. OleDb—the bridge provider for using OLE DB providers in ADO.NET

4. Odbc—the bridge provider for using ODBC drivers in ADO.NET

In ADO.NET 2.0, all four of these providers have been enhanced to enable their use in partially trusted

environments. By properly configuring .NET code access security (CAS), it is possible to enable more

data-centric mobile code scenarios. In ADO.NET 1.1, only the SqlClient provider supported this feature.

In addition, data providers are written by database companies (Oracle's ODP.NET and IBM's data

provider for DB2), provider specialists (DataDirect Technologies), and open source projects and

individuals. In addition, Microsoft will ship a DB2 data provider in Host Integration Server 2004 product.

Because SQL Server is an important piece of the software puzzle, there are many enhancements to

SqlClient in ADO.NET 2.0, in addition to the enhancements in all Microsoft-supported providers. Some of

this functionality supports any version of SQL Server, while much of the new functionality is meant to

support the many new features available in SQL Server 2005, which may be more easily recognized by

its codename, "Yukon". SQL Server 2005 supports .NET code running inside the server, and there are

optimizations for data access inside the server using the provider model as well. One big internal change

that is not immediately evident is that the SqlClient data provider in ADO.NET 2.0 does not use the

Microsoft Data Access Components (MDAC). There is also better error handling in the provider, with

clearer error messages for network errors and more granular error messages overall. Here's an overview

of the programmer-visible SqlClient-specific functionality.

Connection Pooling Enhancements

ADO.NET 1.0 introduced a new infrastructure for pooling database connections. The Microsoft SqlClient

and OracleClient data providers use this infrastructure; the OleDb and Odbc data providers do not. The

new pooling mechanism provided granular support of connection pooling parameters, including

minimum and maximum pool sizes and the ability for the pool manager to wait for a user-defined amount

of time for a connection to become available in the pool. ADO.NET adds a connection-pooling

enhancement that allows you to programmatically "drain" the connection pool; that is, close all of the

connections currently kept alive by the pooler. You can clear a specific connection pool by using the static

(shared in Visual Basic .NET) method SqlConnection.ClearPool or clear all of the connection pools in an

appdomain by using the SqlConnection.ClearPools method. Both SqlClient and OracleClient

implement this functionality.

Asynchronous Commands

Sometimes in client or middleware code, you want to do more than one thing at the same time. In

inherently multithreaded middleware code, this is a key factor for increasing throughput. In ADO.NET 2.0,

SqlClient now supports asynchronous command execution.

The .NET paradigm for asynchronous operations is to provide a set of Begin and End methods for an

operation, as well as a method for synchronous operation. Because database command execution can

take a long time, SqlClient now provides built-in SqlCommand methods that provide asynchronous

execution. Methods that support asynchronous execution and their synchronous counterparts are listed

in the table below.

Synchronous Method Asynchronous Methods

ExecuteNonQuery BeginExecuteNonQuery, EndExecuteNonQuery

ExecuteReader BeginExecuteReader, EndExecuteReader

ExecuteXmlReader BeginExecuteXmlReader, EndExecuteXmlReader

Although asynchronous execution can be a nice feature, it should not be used gratuitously; only use it if

you know the command can run for a long time, and also that you have something useful to do at the

same time. The Windows thread scheduler in the Windows NT family of operating systems (the feature

is not available on Windows 9x and Me clients) takes overhead of its own to switch between threads. Also

bear in mind that some .NET libraries are thread-sensitive; using asynchrony, the thread that you use to

start the operation won't necessarily be the same thread it finishes on. However, the SQL Server network

library stack has been enhanced to support asynchrony by means of I/O completion ports and this

provides better throughput for asynchronous SQL Server operations. Not only can asynchronous

operation be effective for multiple action statements and stored procedure execution, when used with the

multiple active resultset feature in SQL Server 2005, you can multiplex asynchronous SELECT

statements using a single database connection.

Bulk Import

Many database applications can INSERT rows into SQL Server in large batches, quickly. The canonical

example of this is an application that inserts rows into SQL Server that correspond to readings from a

hardware device, such as a telephone switch or a hospital patient monitor. Although SQL Server comes

with utilities (like bcp) to accommodate this, these typically use a file for their input.

SqlClient contains a new class called SqlBulkCopy. This class is not meant to directly consume input

from files and produce file output like BCP, but to accommodate inserting many rows into the database

from a client quickly and efficiently. SqlBulkCopy can get its input from DataReaders and DataSets. This

means that you can not only stream a series of rows from a provider directly (DataReader), but also fill

DataSets with outside data obtained from a hardware device that is not a provider and update this

directly; in this case, no provider is needed as a source.

// Fill up a DataSet

DataSet ds = new DataSet();

FillDataSetFromHardwareDevice(ds);

// Copy the Data to SqlServer

string connect_string = GetConnectStringFromConfigFile();

SqlBulkCopy bcp = new SqlBulkCopy(connect_string);

bcp.DestinationTableName = "hardware_readings";

bcp.WriteToServer(ds);

Provider Statistics

Some application writers find it useful to do "real-time" monitoring in their application. Although you

could use Windows Performance Monitor, define your own performance classes, and use internal (and

possibly fragile, over time) SQL Server metadata calls to obtain this information, SqlClient now has a

built-in way to provide this information for you. An instance method on the SqlConnection class lets you

harvest per-connection statistics that are similar to those available in the ODBC API. Because storing and

gathering these statistics takes overhead of its own, there is a property that can be used to toggle

statistics gathering. There is also a method to reset the counters. Statistics gathering is turned off by

default, of course, and is also set off when you return a connection to the connection pool by calling

Dispose or Close in a pooling scenario. Here is an example of the statistics produced.

string connect_string = GetConnectStringFromConfigFile();

SqlConnection conn = new SqlConnection(connect_string);

conn.Open();

// Enable

conn.StatisticsEnabled = true;

// do some operations

//

SqlCommand cmd = new SqlCommand("select * from authors", conn);

SqlDataReader rdr = cmd.ExecuteReader();

Hashtable stats = (Hashtable)conn.RetrieveStatistics();

// process stats

IDictionaryEnumerator e = stats.GetEnumerator();

while (e.MoveNext())

Console.WriteLine("{0} : {1}", e.Key, e.Value);

conn.ResetStatistics();

Connection-specific statistics

BuffersReceived : 1

BuffersSent : 1

BytesReceived : 220

BytesSent : 72

ConnectionTime : 149

CursorFetchCount : 0

CursorFetchTime : 0

CursorOpens : 0

CursorUsed : 0

ExecutionTime : 138

IduCount : 0

IduRows : 0

NetworkServerTime : 79

PreparedExecs : 0

Prepares : 0

SelectCount : 0

SelectRows : 0

ServerRoundtrips : 1

SumResultSets : 0

Transactions : 0

UnpreparedExecs : 1

For more information about exactly what these statistics represent, consult the ADO.NET 2.0 or the

ODBC documentation.

AttachDbFileName

The SqlClient data provider supports desktop applications (in which the database is stored on a user's

desktop) as well as client-server and middleware-based applications. There is a special version of SQL

Server known as MSDE; the SQL Server 2005 era name for this product is SQL Server 2005 Express

Edition. In desktop applications, the database itself is application-specific and bundled with the

application. The user may even be unaware that SQL Server is being used as the data repository, as the

application setup program will run the SQL Server Express installation.

To facilitate attaching the database files to the SQL Server Express instance inside of an application,

ADO.NET 1.0 provided a connection string parameter, AttachDbFileName. This parameter had to be

specified as a hard-coded pathname, however, making it difficult for users to install the application in a

location other than the default. In ADO.NET 2.0, the AttachDbFileName parameter can be a relative path,

and is used in conjunction with application configuration settings. This makes setting up a desktop

application for SQL Server Express as easy as connecting to a Microsoft Access file-based data store.

SQL Server 2005-Specific Features in SqlClient

MARS

When you select a set of rows using a SQL SELECT statement, either as a stand-alone or inside a stored

procedure, SQL Server doesn't automatically produce a cursor over the set of rows as some databases do.

Instead, it uses an optimized method to stream the resultset across the network, on occasions reading

from the database buffers directly as the network library pulls the data in packet-size chunks. This is

known as "the default resultset of SQL Sever" in SQL Server Boks Oline, or "the cursorless resultset". In

versions of SQL Server prior to SQL Server 2005, there could only be a single cursorless resultset active

on a single connection at a time.

Different database APIs and libraries dealt with the one connection/one cursorless resultset behavior

differently. ADO.NET 1.0 and 1.1 throw an error if you attempt to open a second cursorless resultset;

ADO "classic" actually opened a new database connection behind the scenes. Opening a new database

connection was more convenient, though less "precisely correct" than throwing an error; this

convenience feature was inadvertently abused by some programmers and resulted in more database

connections than they bargained for.

In SQL Server 2005, the database has been enhanced to permit multiple cursorless resultsets to be

active on a single connection at a time. This produces the feature acronym "MARS" (multiple active

resultsets). There are changes to the network libraries to support this behavior, and both the new

network libraries and the new database are needed to enable MARS.

In SqlClient code, you multiplex resultsets by having multiple SqlCommand instances use the same

connection. Each SqlCommand can accommodate a SqlDataReader produced by calling

Command.ExecuteReader, and multiple SqlDataReaders can be used in tandem. In ADO.NET 1.0 and

1.1, you must close one SqlDataReader before obtaining another, even if multiple SqlCommand are used.

Note that you cannot multiplex SqlDataReaders produced from multiple ExecuteReader calls on the same

SqlCommand instance. Here's a short (but not very functionally useful) example:

// connection strings should not be hardcoded

string connstr = GetConnStringFromConfigFile();

SqlConnection conn = new SqlConnection(connstr);

SqlCommand cmd1 = new SqlCommand(

"select * from employees", conn)

SqlCommand cmd2 = new SqlCommand(

"select * from jobs", conn)

SqlDataReader rdr1 = cmd1.ExecuteReader();

// next statement causes an error prior to SQL Server 2005

SqlDataReader rdr2 = cmd2.ExecuteReader();

// now you can reader from rdr1 and rdr2 at the same time.

This feature is not just about reducing errors or clarifying what used to be ADO library magic. It can be

extremely useful in conjunction with asynchronous operations described above. Multiple asynchronous

SELECT statements or stored procedure invocations can be executed in tandem, saving database

connections and optimizing throughput. Imagine filling 20 drop-down list boxes on a form at the same

time, using a single connection. You can also execute non-resultset-returning statements while a

resultset is active.

Although multiple streams of execution can be active at the same time, all of the execution streams must

share the same transaction, if a transaction exists. Transactions are still connection-scoped rather than

command-scoped. You associate the SqlTransaction instance with the SqlCommand by setting the

SqlCommand Transaction property as in previous versions of ADO.NET.

SqlDependency and SqlNotificationRequest

It's extremely helpful in middle-tier caching situations to be able to refresh the cache based on the fact

that someone else has changed a row in the database. Programmers have resorted to a few different

techniques to accomplish this, such as writing a trigger that updates a file when the table or view changes,

or refreshing the cache every so often whether the database has changed or not. There is no

straightforward way the register for database notifications until the SqlClient SqlNotificationRequest

and SqlDependency classes.

SqlDependency is a high-level class that wraps a SqlNotificationRequest and presents your notification

information as a .NET event. With SqlNotificationRequest, there is no event and you must "do the heavy

lifting" of registering for the notification and harvesting the information yourself. The great majority of

programmers will use SqlDependency. SqlDependency can be used as a stand-alone and its functionality

is available directly when using the ASP.NET Cache class.

This SQL Server 2005-specific functionality depends on SQL Server Service Broker, a new feature that

implements a scalable queuing system. Note that, when using the ASP.NET Cache class, polling the

database is used instead of Service Broker to achieve similar functionality. When using Service Broker

and SQL Server 2005, you need not maintain a connection to the database in order to be notified.

SqlDependency uses your choice of HTTP or TCP protocols and contacts you when the underlying rows

change. The notification does not contain any row-specific information: when you are notified, you must

fetch the entire set of rows again and re-register for the notification.

This functionality is just what you need for a single cache or a limited set of users, but beware when using

it with large numbers of users listening at the same time. Each user must refresh the entire rowset in

cache when any row changes. With a large number of changes and a large number of users, the SELECT

statements used for refresh could be a significant hit on the database.

Password Changing

SQL Server 2005 provides a mechanism to use SQL logins that are subject to the same expiration as

other password policies that integrated logins (Windows logins connecting to SQL Server). This feature

requires SQL Server 2005 running on Windows Server 2003. If a SQL login password (like 'sa') is going

to expire, you won't be able to use the traditional Windows mechanism and password changing APIs to

change it. You can only change this password using a SQL Server client that ends up calling the Transact

SQL ALTER LOGIN verb.

SqlClient accommodates this through the ChangePassword method on the SqlConnection class. Note

that this method is only useable if executed against a SQL Server 2005 instance; although you can

change a SQL login on older versions of the database, this API uses a network packet type that no other

version of SQL Server supports. Another aspect of password changing to consider is that it is no longer

possible to hard-code SQL Server login IDs and passwords in connection strings in programs. Unless you

are going to produce .NET intermediate language and replace the executable each time the password

changes (this is not a viable option), you must store your SQL Server password in a configuration file.

Serious SQL Server developers have been using a configuration file to store (hopefully encrypted)

passwords for quite a while. Better yet, always use SQL Server integrated security, if possible.

System.Transactions Integration

The SqlClient provider in ADO.NET 2.0 integrates with the new System.Transactions namespace,

enabling a behavior known as promotable transactions. Although Transact SQL can be used to start a

local or distributed transaction (BEGIN TRANSACTION and BEGIN DISTRIBUTED TRANSACTION), there

are occasions, especially in client-side/middle-tier programming where the programmer may wish to

write a component that could be used in one database or multiple database scenarios. These scenarios

might include multiple SQL Server instances and SQL Server can automatically detect multi-instance

access and "promote" a transaction from local to multi-instance (distributed). This is even possible when

multiple database products or multiple connections are used, as long the first database (known as a

resource manager in distributed transaction terminology) is SQL Server. Promotable transactions are

enabled by default in ADO.NET.

Client Failover

SQL Server 2005 supports a "hot spare" capability through database mirroring. If a SQL Server instance

fails, the work can be shifted over to the backup server automatically. This requires an instance to

witness the failover known as (not surprisingly) the "witness instance". Hot spare scenarios require that

existing client connections must "know" to fail over (establish a connection with the new server instance),

as well. Client connections that produce an error on the next attempted access and must be manually

"failed over" by client programming are suboptimal. SqlClient in ADO.NET 2.0 supports client failover

without special programming of the application program.

Support for New Transaction Isolation Level

SQL Server 2005 supports transaction isolation through two methods, locking and versioning. Previous

versions of SQL Server supported locking but not versioning. Two types of versioning are supported;

these are known as statement-level versioning and transaction-level versioning. The feature is meant to

selectively reduce locking in extreme circumstances and to ease conversion of applications that were

designed for versioning databases. Applications designed for versioning databases often need significant

changes when porting them to a locking database, and vice-versa. The default behavior of a versioning

database is almost always statement-level versioning. For more information on the difference, consult A

First Look at SQL Server 2005 for Developers by Beauchemin, Berglund, and Sullivan.

Both different versioning and different locking behavior equate to starting a transaction using a specific

transaction isolation level. There are four transaction isolation levels defined by the ANSI SQL

specification:

• READ UNCOMMITED

• READ COMMITTED

• REPEATABLE READ

• SERIALIZABLE

SQL Server supports all four isolation levels, and did so even prior to SQL Server 2005. Versioning

databases typically support only READ COMMITTED and SERIALIZABLE. READ COMMITTED implements

statement-level versioning and SERIALIZABLE implements transaction-level versioning in versioning

databases. READ COMMITTED is the default behavior for almost all databases, whether locking or

versioning is used.

Statement-level versioning is enabled and it is the default behavior by setting database options on a per

database basis. When statement versioning is enabled, specifying IsolationLevel.ReadCommitted or

IsolationLevel.ReadUncommitted uses this behavior. To support transaction-level isolation, SQL

Server 2005 defines a new isolation level IsolationLevel.Snapshot. SqlClient (and only SqlClient)

supports this isolation level. This isolation level was required because you can turn on statement-level or

transaction-level versioning separately and IsolationLevel.Serializable is already used by SQL Server

to correspond to locking behavior.

DataTypes - UDTs, the XML data type, and "MAX" BLOBs and CLOBs

SQL Server 2005 adds support for user-defined types, a native XML data type and better large data

support. Large data support is improved by using the Transact-SQL types VARCHAR(MAX),

NVARCHAR(MAX) and VARBINARY(MAX). User-defined types and a native XML type are defined by the

SQL:1999 and SQL:2003 specifications. To use these data types with SqlClient, new classes in the

System.Data.SqlTypes namespace are defined (SqlUdt and SqlXml), support is added to the

SqlDbTypes enumeration and IDataReader.GetValue was enhanced to support returning UDTs

as .NET Object types, and support returning XML as a .NET String.

These new SQL Server 2005 types are supported in DataReaders returned from SQL SELECT statements

and as Parameters using SqlParameter. A special class, SqlMetaData, can return information about

extended properties of these new data types, such as the XML schema collection that a strongly typed

XML column adheres to, or the database name of a UDT. You can use these types from the client directly,

in generic code, and also in the DataSet. Finally you can perform partial updates on the "MAX" data types

from the client, which required using special SQL functions before ADO.NET 2.0. There will be future

articles on this site that delve into the details.

Conclusion

Whew! That's a lot of features, almost too many to keep track of. To help you from drowning in the new

sea of functionality, I conclude with a chart of each new feature and which database, provider, and

version you must have to make it work. I currently only have information on the four providers that are

part of ADO.NET, but other provider vendors will likely join in shortly. In future articles, I hope to expand

the chart.

New Feature Availability

All Providers SQL Server 7/2000 SQL Server 2005

Provider Factories X X X

Runs w/Partial Trust X X X

Server Enumeration X X X

Connection String Builder X X X

Metadata Schemas X X X

Batch Update Support X X X

Provider-Specific Types X X X

Conflict Detection X X X

Tracing Support X X X

Pooling Enhancements SqlClient and

OracleClient

X X

MARS X

SqlNoticicationRequest X

SqlDependency X

IsolationLevel.Snapshot X

Asynch Commands X X X

Client Failover X

Bulk Import X X X

Password Change API X

Statistics X X X

New Datatypes X

Promotable Tx X X

AttachDbFileName X X

Bob Beauchemin is an instructor, course author, and database curriculum course liaison for

DevelopMentor. He has over twenty-five years of experience as an architect, programmer, and

administrator for data-centric distributed systems. He's written articles on ADO.NET, OLE DB and SQL

Server for Microsoft Systems Journal and SQL Server Magazine and others, and is the author of the books,

A First Look at SQL Server 2005 for Developers and Essential ADO.NET

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有