HTTP1.1状态字（原版）- -

10 Status Code Definitions

Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required in the response.

10.1 Informational 1xx

This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.

A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be ignored by a user agent.

Proxies MUST forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response. (For example, if a

proxy adds a "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).)

10.1.1 100 Continue

The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See section 8.2.3 for detailed discussion of the use and handling of this status code.

10.1.2 101 Switching Protocols

The server understands and is willing to comply with the client's request, via the Upgrade message header field (section 14.42), for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response.

The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.

10.2 Successful 2xx

This class of status code indicates that the client's request was successfully received, understood, and accepted.

10.2.1 200 OK

The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

GET an entity corresponding to the requested resource is sent in the response;

HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;

POST an entity describing or containing the result of the action;

TRACE an entity containing the request message as received by the end server.

10.2.2 201 Created

The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.

A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section 14.19.

10.2.3 202 Accepted

The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

10.2.4 203 Non-Authoritative Information

The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK).

10.2.5 204 No Content

The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.

If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.

The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

10.2.6 205 Reset Content

The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity.

10.2.7 206 Partial Content

The server has fulfilled the partial GET request for the resource. The request MUST have included a Range header field (section 14.35) indicating the desired range, and MAY have included an If-Range header field (section 14.27) to make the request conditional.

The response MUST include the following header fields:

      - Either a Content-Range header field (section 14.16) indicating
        the range included with this response, or a multipart/byteranges
        Content-Type including Content-Range fields for each part. If a
        Content-Length header field is present in the response, its
        value MUST match the actual number of OCTETs transmitted in the
        message-body.

      - Date

      - ETag and/or Content-Location, if the header would have been sent
        in a 200 response to the same request

      - Expires, Cache-Control, and/or Vary, if the field-value might
        differ from that sent in any previous response for the same
        variant

If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.

A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see 13.5.4.

A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses.

10.3 Redirection 3xx

This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection.

      Note: previous versions of this specification recommended a
      maximum of five redirections. Content developers should be aware
      that there might be clients that implement such a fixed
      limitation.

10.3.1 300 Multiple Choices

The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of

the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0 user agents
      will erroneously change it into a GET request.

10.3.3 302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.  However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method. The status codes 303 and 307 have
      been added for servers that wish to make unambiguously clear which
      kind of reaction is expected of the client.

10.3.4 303 See Other

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

      Note: Many pre-HTTP/1.1 user agents do not understand the 303
      status. When interoperability with such clients is a concern, the
      302 status code may be used instead, since most user agents react
      to a 302 response as described here for 303.

10.3.5 304 Not Modified

If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.

The response MUST include the following header fields:

      - Date, unless its omission is required by section 14.18.1

If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.

      - ETag and/or Content-Location, if the header would have been sent
        in a 200 response to the same request

      - Expires, Cache-Control, and/or Vary, if the field-value might
        differ from that sent in any previous response for the same
        variant

If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.

If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.

If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.

10.3.6 305 Use Proxy

The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.

      Note: RFC 2068 was not clear that 305 was intended to redirect a
      single request, and to be generated by origin servers only.  Not
      observing these limitations has significant security consequences.

10.3.7 306 (Unused)

The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.

10.3.8 307 Temporary Redirect

The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.

If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

10.4 Client Error 4xx

The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user.

If the client is sending data, a server implementation using TCP SHOULD be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted by the HTTP application.

10.4.1 400 Bad Request

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

10.4.2 401 Unauthorized

The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].

10.4.3 402 Payment Required

This code is reserved for future use.

10.4.4 403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

10.4.6 405 Method Not Allowed

The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.

10.4.7 406 Not Acceptable

The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

      Note: HTTP/1.1 servers are allowed to return responses which are
      not acceptable according to the accept headers sent in the
      request. In some cases, this may even be preferable to sending a
      406 response. User agents are encouraged to inspect the headers of
      an incoming response to determine if it is acceptable.

If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.

10.4.8 407 Proxy Authentication Required

This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].

10.4.9 408 Request Timeout

The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.

10.4.10 409 Conflict

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough

information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.

Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.

10.4.11 410 Gone

The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.

The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.

10.4.12 411 Length Required

The server refuses to accept the request without a defined Content- Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.

10.4.13 412 Precondition Failed

The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.

10.4.14 413 Request Entity Too Large

The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.

If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again.

10.4.15 414 Request-URI Too Long

The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI.

10.4.16 415 Unsupported Media Type

The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.

10.4.17 416 Requested Range Not Satisfiable

A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.)

When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource (see section 14.16). This response MUST NOT use the multipart/byteranges content- type.

10.4.18 417 Expectation Failed

The expectation given in an Expect request-header field (see section 14.20) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.

10.5 Server Error 5xx

Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method.

10.5.1 500 Internal Server Error

The server encountered an unexpected condition which prevented it from fulfilling the request.

10.5.2 501 Not Implemented

The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.

10.5.3 502 Bad Gateway

The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.

10.5.4 503 Service Unavailable

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.

      Note: The existence of the 503 status code does not imply that a
      server must use it when becoming overloaded. Some servers may wish
      to simply refuse the connection.

10.5.5 504 Gateway Timeout

The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.

      Note: Note to implementors: some deployed proxies are known to
      return 400 or 500 when DNS lookups time out.

10.5.6 505 HTTP Version Not Supported

The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.

本文为您提供了在 Microsoft ADO.NET 应用程序中实现和获得最佳性能、可伸缩性以及功能的最佳解决方案；同时也讲述了使用 ADO.NET 中可用对象的最佳实践；并提出一些有助于优化 ADO.NET 应用程序设计的建议。

本文包含：

使用 DataReader、DataSet、DataAdapter 和 DataView

ADO.NET 提供以下两个对象，用于检索关系数据并将其存储在内存中：DataSet 和 DataReader。DataSet 提供一个内存中数据的关系表示形式，一整套包括一些表在内的数据（这些表包含数据、对数据进行排序并约束数据），以及表之间的关系。DataReader 提供一个来自数据库的快速、只进、只读数据流。

当使用 DataSet 时，经常会利用 DataAdapter（也可能是 CommandBuilder）与数据源进行交互。当使用 DataSet 时，也可以利用 DataView 对 DataSet 中的数据应用排序和筛选。也可以从 DataSet 继承，创建强类型 DataSet，用于将表、行和列作为强类型对象属性公开。

下列主题包括的信息涉及：使用 DataSet 或 DataReader 的最佳时机、如何优化访问它们所包含数据、以及如何优化使用 DataAdapter（包括 CommandBuilder）和 DataView 的技巧。

DataSet 与 DataReader

当设计应用程序时，要考虑应用程序所需功能的等级，以确定使用 DataSet 或者是 DataReader。

要通过应用程序执行以下操作，就要使用 DataSet：

对于下列情况，要在应用程序中使用 DataReader：

注填充 DataSet 时，DataAdapter 使用 DataReader。因此，使用 DataAdapter 取代 DataSet 提升的性能表现为节省了 DataSet 占用内存和填充 DataSet 需要的循环。一般来说，此性能提升只是象征性的，因此，设计决策应以所需功能为基础。

使用强类型 DataSet 的好处

DataSet 的另一个好处是可被继承以创建一个强类型 DataSet。强类型 DataSet 的好处包括设计时类型检查，以及 Microsoft Visual Studio .NET 用于强类型 DataSet 语句结束所带来的好处。修改了 DataSet 的架构或关系结构后，就可以创建一个强类型 DataSet，把行和列作为对象的属性公开，而不是作为集合中的项公开。例如，不公开客户表中行的姓名列，而公开 Customer 对象的 Name 属性。类型化 DataSet 从 DataSet 类派生，因此不会牺牲 DataSet 的任何功能。也就是说，类型化 DataSet 仍能远程访问，并作为数据绑定控件（例如 DataGrid）的数据源提供。如果架构事先不可知，仍能受益于通用 DataSet 的功能，但却不能受益于强类型 DataSet 的附加功能。

处理强类型 DataSet 中的空引用

使用强类型 DataSet 时，可以批注 DataSet 的 XML 架构定义语言 (XSD) 架构，以确保强类型 DataSet 正确处理空引用。nullValue 批注使您可用一个指定的值 String.Empty 代替 DBNull、保留空引用或引发异常。选择哪个选项取决于应用程序的上下文。默认情况下，如果遇到空引用，就会引发异常。

有关更多信息，请参阅 Working with a Typed DataSet。

刷新 DataSet 中的数据

如果想用服务器上的更新值刷新 DataSet 中的值，就使用 DataAdapter.Fill。如果有在 DataTable 上定义的主键，DataAdapter.Fill 会根据主键进行新行匹配，并且当更改到现有行时应用服务器上的值。即使刷新之前修改了它们，刷新行的 RowState 仍被设置为 Unchanged。注意，如果没有为 DataTable 定义主键，DataAdapter.Fill 就用可能重复的主键值添加新行。

如果想用来自服务器的当前值刷新表，并同时保留对表中的行所做的任何更改，必须首先用 DataAdapter.Fill 填充表，并填充一个新的 DataTable，然后用 preserveChanges 值 true 把 DataTableMerge 到 DataSet 中。

在 DataSet 中搜索数据

在 DataSet 中查询与特定条件相匹配的行时，可以利用基于索引的查找提高搜索性能。当把 PrimaryKey 值赋给 DataTable 时，会创建一个索引。当给 DataTable 创建 DataView 时，也会创建一个索引。下面是一些利用基于索引进行查找的技巧。

DataView 构造

如果创建了 DataView，并且修改了 Sort、RowFilter 或 RowStateFilter 属性，DataView 就会为基础 DataTable 中的数据建立索引。创建 DataView 对象时，要使用 DataView 构造函数，它用 Sort、RowFilter 和 RowStateFilter 值作为构造函数参数（与基础 DataTable 一起）。结果是创建了一次索引。创建一个“空”DataView 并随后设置 Sort、RowFilter 或 RowStateFilter 属性，会导致索引至少创建两次。

分页

ADO.NET 可以显式控制从数据源中返回什么样的数据，以及在 DataSet 中本地缓存多少数据。对查询结果的分页没有唯一的答案，但下面有一些设计应用程序时应该考虑的技巧。

SELECT TOP 10 * FROM
  (SELECT TOP 30 * FROM Customers ORDER BY Id ASC) AS Table1
ORDER BY Id DESC

有关更多信息，请参阅 .NET Data Access Architecture Guide。

用架构填充 DataSet

当用数据填充 DataSet 时，DataAdapter.Fill 方法使用 DataSet 的现有架构，并使用从 SelectCommand 返回的数据填充它。如果在 DataSet 中没有表名与要被填充的表名相匹配，Fill 方法就会创建一个表。默认情况下，Fill 仅定义列和列类型。

通过设置 DataAdapter 的 MissingSchemaAction 属性，可以重写 Fill 的默认行为。例如，要让 Fill 创建一个表架构，并且还包括主键信息、唯一约束、列属性、是否允许为空、最大列长度、只读列和自动增量的列，就要把 DataAdapter.MissingSchemaAction 指定为 MissingSchemaAction.AddWithKey。或者，在调用 DataAdapter.Fill 前，可以调用 DataAdapter.FillSchema 来确保当填充 DataSet 时架构已到位。

对 FillSchema 的调用会产生一个到服务器的额外行程，用于检索附加架构信息。为了获得最佳性能，需要在调用 Fill 之前指定 DataSet 的架构，或者设置 DataAdapter 的 MissingSchemaAction。

使用 CommandBuilder 的最佳实践

假设 SelectCommand 执行单一表 SELECT，CommandBuilder 就会以 DataAdapter 的 SelectCommand 属性为基础自动生成 DataAdapter 的 InsertCommand、UpdateCommand、和 DeleteCommand 属性。下面是为获得最佳性能而使用 CommandBuilder 的一些技巧。

批处理 SQL 语句

很多数据库支持把多条命令合并或批处理成一条单一命令执行。例如，SQL Server 使您可以用分号 (;) 分隔命令。把多条命令合并成单一命令，能减少到服务器的行程数，并提高应用程序的性能。例如，可以把所有预定的删除在应用程序中本地存储起来，然后再发出一条批处理命令调用，从数据源删除它们。

虽然这样做确实能提高性能，但是，当对 DataSet 中的数据更新进行管理时，可能会增加应用程序的复杂性。要保持简单，可能要在 DataSet 中为每个 DataTable 创建一个 DataAdapter。

用多个表填充 DataSet

如果使用批处理 SQL 语句检索多个表并填充 DataSet，第一个表用指定给 Fill 方法的表名命名。后面的表用指定给 Fill 方法的表名加上一个从 1 开始并且增量为 1 的数字命名。例如，如果运行下面的代码：

'Visual Basic
Dim da As SqlDataAdapter = New SqlDataAdapter("SELECT * FROM Customers; SELECT * FROM Orders;", myConnection)
Dim ds As DataSet = New DataSet()
da.Fill(ds, "Customers")

//C#
SqlDataAdapter da = new SqlDataAdapter("SELECT * FROM Customers; SELECT * FROM Orders;", myConnection);
DataSet ds = new DataSet();
da.Fill(ds, "Customers");

来自 Customers 表的数据放在名为 "Customers" 的 DataTable 中。来自 Orders 表的数据放在名为 "Customers1" 的 DataTable 中。

填充完 DataSet 之后，可以很容易地把 "Customers1" 表的 TableName 属性改为 "Orders"。但是，后面的填充会导致 "Customers" 表被重新填充，而 "Orders" 表会被忽略，并创建另外一个 "Customers1" 表。为了对这种情况作出补救，创建一个 DataTableMapping，把 "Customers1" 映射到 "Orders"，并为其他后面的表创建其他的表映射。例如：

'Visual Basic
Dim da As SqlDataAdapter = New SqlDataAdapter("SELECT * FROM Customers; SELECT * FROM Orders;", myConnection)
da.TableMappings.Add("Customers1", "Orders")
Dim ds As DataSet = New DataSet()
da.Fill(ds, "Customers")

//C#
SqlDataAdapter da = new SqlDataAdapter("SELECT * FROM Customers; SELECT * FROM Orders;", myConnection);
da.TableMappings.Add("Customers1", "Orders");
DataSet ds = new DataSet();
da.Fill(ds, "Customers");

使用 DataReader

下面是一些使用 DataReader 获得最佳性能的技巧，同时还回答了一些关于使用 DataReader 的常见问题。

二进制大对象 (BLOB)

用 DataReader 检索二进制大对象 (BLOB) 时，应该把 CommandBehavior.SequentialAccess 传递给 ExecuteReader 方法调用。因为 DataReader 的默认行为是每次 Read 都把整行加载到内存，又因为 BLOB 值可能非常大，所以结果可能由于单个 BLOB 而使大量内存被用光。SequentialAccess 将 DataReader 的行为设置为只加载请求的数据。然后还可以使用 GetBytes 或 GetChars 控制每次加载多少数据。

记住，使用 SequentialAccess 时，不能不按顺序访问 DataReader 返回的不同字段。也就是说，如果查询返回三列，其中第三列是 BLOB，并且想访问前两列中的数据，就必须在访问 BLOB 数据之前先访问第一列的值，然后访问第二列的值。这是因为现在数据是顺序返回的，并且 DataReader 一旦读过该数据，该数据就不再可用。

有关如何在 ADO.NET 中访问 BLOB 的详细描述，请参阅 Obtaining BLOB Values from a Database。

使用命令

ADO.NET 提供了几种命令执行的不同方法以及优化命令执行的不同选项。下面包括一些技巧，它们是关于选择最佳命令执行以及如何提高执行命令的性能。

使用 OleDbCommand 的最佳实践

不同 .NET 框架数据提供程序之间的命令执行被尽可能标准化了。但是，数据提供程序之间仍然存在差异。下面给出一些技巧，可微调用于 OLE DB 的 .NET 框架数据提供程序的命令执行。

使用 SqlCommand 的最佳实践

使用 SqlCommand 执行存储过程的快速提示：如果调用存储过程，将 SqlCommand 的 CommandType 属性指定为 StoredProcedure 的 CommandType。这样通过将该命令显式标识为存储过程，就不需要在执行之前分析命令。

使用 Prepare 方法

对于重复作用于数据源的参数化命令，Command.Prepare 方法能提高性能。Prepare 指示数据源为多次调用优化指定的命令。要想有效利用 Prepare，需要彻底理解数据源是如何响应 Prepare 调用的。对于一些数据源（例如 SQL Server 2000），命令是隐式优化的，不必调用 Prepare。对于其他（例如 SQL Server 7.0）数据源，Prepare 会比较有效。

显式指定架构和元数据

只要用户没有指定元数据信息，ADO.NET 的许多对象就会推断元数据信息。下面是一些示例：

但是，每次用到这些特性，都会有性能损失。建议将这些特性主要用于设计时和即席应用程序中。在可能的情况下，显式指定架构和元数据。其中包括在 DataSet 中定义表和列、定义 DataAdapter 的 Command 属性、以及为 Command 定义 Parameter 信息。

ExecuteScalar 和 ExecuteNonQuery

如果想返回像 Count(*)、Sum(Price) 或 Avg(Quantity) 的结果那样的单值，可以使用 Command.ExecuteScalar。ExecuteScalar 返回第一行第一列的值，将结果集作为标量值返回。因为单独一步就能完成，所以 ExecuteScalar 不仅简化了代码，还提高了性能；要是使用 DataReader 就需要两步才能完成（即，ExecuteReader + 取值）。

使用不返回行的 SQL 语句时，例如修改数据（例如INSERT、UPDATE 或 DELETE）或仅返回输出参数或返回值，请使用 ExecuteNonQuery。这避免了用于创建空 DataReader 的任何不必要处理。

有关更多信息，请参阅 Executing a Command。

测试 Null

如果表（在数据库中）中的列允许为空，就不能测试参数值是否“等于”空。相反，需要写一个 WHERE 子句，测试列和参数是否都为空。下面的 SQL 语句返回一些行，它们的 LastName 列等于赋给 @LastName 参数的值，或者 LastName 列和 @LastName 参数都为空。

SELECT * FROM Customers
WHERE ((LastName = @LastName) OR (LastName IS NULL AND @LastName IS NULL))

把 Null 作为参数值传递

对数据库的命令中，当把空值作为参数值发送时，不能使用 null（Visual Basic庐 .NET 中为 Nothing）。而需要使用 DBNull.Value。例如：

'Visual Basic
Dim param As SqlParameter = New SqlParameter("@Name", SqlDbType.NVarChar, 20)
param.Value = DBNull.Value

//C#
SqlParameter param = new SqlParameter("@Name", SqlDbType.NVarChar, 20);
param.Value = DBNull.Value;

执行事务

ADO.NET 的事务模型已经更改。在 ADO 中，当调用 StartTransaction 时，调用之后的任何更新操作都被视为是事务的一部分。但是，在 ADO.NET 中，当调用 Connection.BeginTransaction 时，会返回一个 Transaction 对象，需要把它与 Command 的 Transaction 属性联系起来。这种设计可以在一个单一连接上执行多个根事务。如果未将 Command.Transaction 属性设置为一个针对相关的 Connection 而启动的 Transaction，那么 Command 就会失败并引发异常。

即将发布的 .NET 框架将使您可以在现有的分布式事务中手动登记。这对于对象池方案来说很理想；在该方案中，一个池对象打开一次连接，但是在多个独立的事务中都涉及到该对象。.NET 框架 1.0 发行版中这一功能并不可用。

有关事务的更多信息，请参阅 Performing Transactions 以及 .NET Data Access Architecture Guide。

使用连接

高性能应用程序与使用中的数据源保持最短时间的连接，并且利用性能增强技术，例如连接池。下面的主题提供一些技巧，有助于在使用 ADO.NET 连接到数据源时获得更好的性能。

连接池

用于 ODBC 的 SQL Server、OLE DB 和 .NET 框架数据提供程序隐式缓冲连接。通过在连接字符串中指定不同的属性值，可以控制连接池的行为。有关如何控制连接池的行为的详细信息，请参阅 Connection Pooling for the SQL Server .NET Data Provider 和 Connection Pooling for the OLE DB .NET Data Provider。

用 DataAdapter 优化连接

DataAdapter 的 Fill 和 Update 方法在连接关闭的情况下自动打开为相关命令属性指定的连接。如果 Fill 或 Update 方法打开了连接，Fill 或 Update 将在操作完成的时候关闭它。为了获得最佳性能，仅在需要时将与数据库的连接保持为打开。同时，减少打开和关闭多操作连接的次数。

如果只执行单个的 Fill 或 Update 方法调用，建议允许 Fill 或 Update 方法隐式打开和关闭连接。如果对 Fill 和/或 Update 调用有很多，建议显式打开连接，调用 Fill 和/或 Update，然后显式关闭连接。

另外，当执行事务时，显式地在开始事务之前打开连接，并在提交之后关闭连接。例如：

'Visual Basic
Public Sub RunSqlTransaction(da As SqlDataAdapter, myConnection As SqlConnection, ds As DataSet)
  myConnection.Open()
  Dim myTrans As SqlTransaction = myConnection.BeginTransaction()
  myCommand.Transaction = myTrans

  Try
    da.Update(ds)
    myTrans.Commit()
    Console.WriteLine("Update successful.")
  Catch e As Exception
    Try
      myTrans.Rollback()
    Catch ex As SqlException
      If Not myTrans.Connection Is Nothing Then
        Console.WriteLine("An exception of type " & ex.GetType().ToString() & _
                          " was encountered while attempting to roll back the transaction.")
      End If
    End Try

    Console.WriteLine("An exception of type " & e.GetType().ToString() & " was encountered.")
    Console.WriteLine("Update failed.")
  End Try
  myConnection.Close()
End Sub

//C#
public void RunSqlTransaction(SqlDataAdapter da, SqlConnection myConnection, DataSet ds)
{
  myConnection.Open();
  SqlTransaction myTrans = myConnection.BeginTransaction();
  myCommand.Transaction = myTrans;

  try
  {
    da.Update(ds);
    myCommand.Transaction.Commit();
    Console.WriteLine("Update successful.");
  }
  catch(Exception e)
  {
    try
    {
      myTrans.Rollback();
    }
    catch (SqlException ex)
    {
      if (myTrans.Connection != null)
      {
        Console.WriteLine("An exception of type " + ex.GetType() +
                          " was encountered while attempting to roll back the transaction.");
      }
    }

    Console.WriteLine(e.ToString());
    Console.WriteLine("Update failed.");
  }
  myConnection.Close();
}

始终关闭 Connection 和 DataReader

完成对 Connection 或 DataReader 对象的使用后，总是显式地关闭它们。尽管垃圾回收最终会清除对象并因此释放连接和其他托管资源，但垃圾回收仅在需要时执行。因此，确保任何宝贵的资源被显式释放仍然是您的责任。并且，没有显式关闭的 Connections 可能不会返回到池中。例如，一个超出作用范围却没有显式关闭的连接，只有当池大小达到最大并且连接仍然有效时，才会被返回到连接池中。

注 不要在类的 Finalize 方法中对 Connection、DataReader 或任何其他托管对象调用 Close 或 Dispose。最后完成的时候，仅释放类自己直接拥有的非托管资源。如果类没有任何非托管资源，就不要在类定义中包含 Finalize 方法。

在 C# 中使用 "Using" 语句

对于 C# 程序员来说，确保始终关闭 Connection 和 DataReader 对象的一个方便的方法就是使用 using 语句。using 语句在离开自己的作用范围时，会自动调用被“使用”的对象的 Dispose。例如：

//C#
string connString = "Data Source=localhost;Integrated Security=SSPI;Initial Catalog=Northwind;";

using (SqlConnection conn = new SqlConnection(connString))
{
  SqlCommand cmd = conn.CreateCommand();
  cmd.CommandText = "SELECT CustomerId, CompanyName FROM Customers";
  
  conn.Open();

  using (SqlDataReader dr = cmd.ExecuteReader())
  {
    while (dr.Read())
      Console.WriteLine("{0}\t{1}", dr.GetString(0), dr.GetString(1));
  }
}

Using 语句不能用于 Microsoft庐 Visual Basic庐 .NET。

避免访问 OleDbConnection.State 属性

如果连接已经打开，OleDbConnection.State 属性会对 DBPROP_CONNECTIONSTATUS 属性的 DATASOURCEINFO 属性集执行本地 OLE DB 调用 IDBProperties.GetProperties，这可能会导致对数据源的往返行程。也就是说，检查 State 属性的代价可能很高。所以仅在需要时检查 State 属性。如果需要经常检查该属性，监听 OleDbConnection 的 StateChange 事件可能会使应用程序的性能好一些。有关 StateChange 事件的详细信息，请参阅 Working with Connection Events。

与 XML 集成

ADO.NET 在 DataSet 中提供了广泛的 XML 集成，并公开了 SQL Server 2000 及其更高版本提供的部分 XML 功能。还可以使用 SQLXML 3.0 广泛地访问 SQL Server 2000 及其更高版本中的 XML 功能。下面是使用 XML 和 ADO.NET 的技巧和信息。

DataSet 和 XML

DataSet 与 XML 紧密集成，并提供如下功能：

注 可以使用这种同步把 XML 功能（例如，XPath 查询和 XSLT 转换）应用到 DataSet 中的数据，或者在保留原始 XML 保真度的前提下为 XML 文档中数据的全部或其中一个子集提供关系视图。

关于 DataSet 提供的 XML 功能的详细信息，请参阅 XML and the DataSet。

架构推断

从 XML 文件加载 DataSet 时，可以从 XSD 架构加载 DataSet 架构，或者在加载数据前预定义表和列。如果没有可用的 XSD 架构，而且不知道为 XML 文件的内容定义哪些表和列，就可以在 XML 文档结构的基础上对架构进行推断。

架构推断作为迁移工具很有用，但应只限于设计阶段应用程序，这是由于推断处理有如下限制。

有关更多信息，请参阅 Inferring DataSet Relational Structure from XML。

用于 XML 查询的 SQL Server

如果正从 SQL Server 2000 FOR XML 返回查询结果，可以让用于 SQL Server 的 .NET 框架数据提供程序使用 SqlCommand.ExecuteXmlReader 方法直接创建一个 XmlReader。

SQLXML 托管类

.NET 框架中有一些类，公开用于 SQL Server 2000 的 XML 的功能。这些类可在 Microsoft.Data.SqlXml 命名空间中找到，它们添加了执行 XPath 查询和 XML 模板文件以及把 XSLT 转换应用到数据的能力。

SQLXML 托管类包含在用于 Microsoft SQL Server 2000 的 XML (SQLXML 2.0) 发行版中，可从 XML for Microsoft SQL Server 2000 Web Release 2 (SQLXML 2.0) 获得。

更多有用的技巧

下面是一些编写 ADO.NET 代码时的通用技巧。

避免自动增量值冲突

就像大多数数据源一样，DataSet 使您可标识那些添加新行时自动对其值进行递增的列。在 DataSet 中使用自动增量的列时，如果自动增量的列来自数据源，可避免添加到 DataSet 的行和添加到数据源的行之间本地编号冲突。

例如，考虑一个表，它的主键列 CustomerID 是自动增量的。两个新的客户信息行添加到表中，并接收到自动增量的 CustomerID 值 1 和 2。然后，只有第二个客户行被传递给 DataAdapter 的方法 Update，新添加的行在数据源接收到一个自动增量的 CustomerID 值 1，与 DataSet 中的值 2 不匹配。当 DataAdapter 用返回值填充表中第二行时，就会出现约束冲突，因为第一个客户行已经使用了 CustomerID 值 1。

要避免这种情况，建议在使用数据源上自动增量的列以及 DataSet 上自动增量的列时，把 DataSet 中的列创建为 AutoIncrementStep 值等于 -1 并且 AutoIncrementSeed 值等于 0，另外，还要确保数据源生成的自动增量标识值从 1 开始，并且以正阶值递增。因此，DataSet 为自动增量值生成负数，与数据源生成的正自动增量值不冲突。另外一个选择是使用 Guid 类型的列，而不是自动增量的列。生成 Guid 值的算法应该永远不会使数据源中生成的 Guid 值与 DataSet 中生成的 Guid 值一样。

如果自动增量的列只是用作唯一值，而且没有任何意义，就考虑使用 Guid 代替自动增量的列。它们是唯一的，并且避免了使用自动增量的列所必需的额外工作。

有关从数据源检索自动增量的列值的示例，请参阅 Retrieving Identity or AutoNumber Values。

检查开放式并发冲突

按照设计，由于 DataSet 是与数据源断开的，所以，当多个客户端在数据源上按照开放式并发模型更新数据时，需要确保应用程序避免冲突。

在测试开放式并发冲突时有几项技术。一项技术涉及在表中包含时间戳列。另外一项技术是，验证一行中所有列的原始值是否仍然与通过在 SQL 语句中使用 WHERE 子句进行测试时在数据库中找到的值相匹配。

有关包含代码示例的该主题的详细讨论，请参阅 Optimistic Concurrency。

多线程编程

ADO.NET 对性能、吞吐量和可伸缩性进行优化。因此，ADO.NET 对象不锁定资源，并且必须只用于单线程。一个例外是 DataSet，它对多个阅读器是线程安全的。但是，在写的时候需要把 DataSet 锁定。

仅在需要的时候才用 COM Interop 访问 ADO

ADO.NET 的设计目的是成为许多应用程序的最佳解决方案。但是，有些应用程序需要只有使用 ADO 对象才有的功能，例如，ADO 多维 (ADOMD)。在这些情况下，应用程序可以用 COM Interop 访问 ADO。注意使用 COM Interop 访问具有 ADO 的数据会导致性能降低。在设计应用程序时，首先在实现用 COM Interop 访问 ADO 的设计之前，先确定 ADO.NET 是否满足设计需求。

META 标签，是 HTML 语言 head 区的一个辅助性标签。在几乎所有的网页里，我们都可以看到类似下面这段 html 代码：  
----------------------------------------------- 
< head> 
< META http-equiv="Content-Type" content="text/html; charset=gb2312"> 
< /head> 
----------------------------------------------- 
　　 这就是 META 标签的典型运用。 META 标签有多少参数，有什么作用，为什么我们要特别重视它呢？让我们一起来发掘 META 标签的奥妙 !  
　　 根据 HTML 语言标准注释： META 标签是对网站发展非常重要的标签，它可以用于鉴别作者，设定页面格式，标注内容提要和关键字，以及刷新页面等等。  
　　 META 标签分两大部分： HTTP-EQUIV 和 NAME 变量。  
　　 ● HTTP-EQUIV 类似于 HTTP 的头部协议，它回应给浏览器一些有用的信息，以帮助正确和精确地显示网页内容。常用的 HTTP-EQUIV 类型有：  
　　 1.expires: 期限   
　　说明：可以用于设定网页的到期时间。一旦网页过期，必须到服务器上重新调阅。  
　　用法： < META HTTP-EQUIV="expires" CONTENT="Wed, 26 Feb 1997 08:21:57 GMT">  
　　注意：必须使用 GMT 的时间格式。  
　　 2.Pragma:cach 模式   
　　 说明：禁止浏览器从本地机的缓存中调阅页面内容。  
　　 用法： < META HTTP-EQUIV="Pragma" CONTENT="no-cache">  
　　 注意：这样设定，访问者将无法脱机浏览。  
　　 3.Refresh: 刷新   
　　 说明：需要定时让网页自动链接到其它网页的话，就用这句了。  
　　 用法： < META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://www.yahoo.com">   
　　 注意：其中的 5 是指停留 5 秒钟后自动刷新到 URL 网址。  
　　 4.Set-Cookie:cookie 设定   
　　 说明：如果网页过期，那么存盘的 cookie 将被删除。  
　　 用法： < META HTTP-EQUIV="Set-Cookie" CONTENT="cookievalue=xxx; expires=Wednesday, 21-Oct-98 16:14:21 GMT; path=/">  
　　 注意：必须使用 GMT 的时间格式。  
　　 5.Window-target:显示窗口的设定   
　　 说明：强制页面在当前窗口以独立页面显示。  
　　 用法： < META HTTP-EQUIV="Window-target" CONTENT="_top">  
　　 注意：用来防止别人在框架里调用你的页面。  
　　 6.Content-Type:显示字符集的设定   
　　 说明：设定页面使用的字符集。 ( 我们在前面字体设计中已经介绍过它的作用   
　　 用法： < META http-equiv="Content-Type" content="text/html; charset=gb2312">  
　　 ● meat 标签的 NAME 变量语法格式是：  
　　 < META NAME="xxx" CONTENT="xxxxxxxxxxxxxxxxxx">  
　　 其中 xxx 主要有下面几种参数：  
　　 1.Keywords: 关键字   
　　 说明： keywords 用来告诉搜索引擎你网页的关键字是什么。  
　　 举例： < META NAME ="keywords" CONTENT="life, universe, mankind, plants, relationships, the meaning of life, science">  
　　 2.description: 简介   
　　 说明： description 用来告诉搜索引擎你的网站主要内容。  
　　 举例： < META NAME="description" CONTENT="This page is about the meaning of life, the universe, mankind and plants.">  
　　 3.robots: 机器人向导   
　　 说明： robots 用来告诉搜索机器人哪些页面需要索引，哪些页面不需要索引。 CONTENT 的参数有 all,none,index,noindex,follow,nofollow 。默认是 all 。  
　　 举例： < META NAME="robots" CONTENT="none">  
　　 4.author: 作者   
　　 说明：标注网页的作者  
　　 举例： < META name="AUTHOR" content="ajie,ajie@netease.com">  
　　 以上是 META 标签的一些基本用法，其中最重要的就是 :Keywords 和 description 的设定。  
　　 为什么呢？道理很简单，这两个语句可以让搜索引擎能准确的发现你，吸引更多的人访问 你的站点 !  
　　 根据现在流行搜索引擎 (Lycos ， AltaVista 等  的工作原理 , 搜索引擎首先派出机器人自动在 www 上搜索，当发现新的网站时，便检索页面中的 keywords 和 decription ，并将其加入到自己的数据库，然后再根据关键词的密度将网站排序。  
　　 也就是说：  
　　 1. 如果你的页面中根本没有 Keywords 和 description 的 META 标签，那么机器人是无法将你的站点加入数据库，网友也就不可能搜索到你的站点。  
　　 2. 如果你的关键字选的不好，关键字的密度不高，被排列在几十甚至几百万个站点的后面被点击的可能性也是非常小的。  
　　 所以 , 我们必须记住添加 keywords 和 description 的 META 标签，并尽可能写好关键字和简介。  
　　 写 keywords 的禁忌是：  
　　 1. 不要用常见词汇。例如 www,homepage,net,web 等。  
　　 2. 不要用形容词，副词。例如最好的，最大的等。  
　　 3. 不要用笼统的词汇，要尽量精确。例如不用"摩托罗拉手机", 改用"V998"等  
　　 寻找合适的关键词的一个技巧是：到 Lycos、Altavista、Infoseek 等搜索引擎，搜索与你内容相仿的网站，查看排名前十位的网站的 META 关键字， copy 下来用到自己的站点上。  
　　 这里，我们举一段微软多媒体网站的关键字供你参考：  
< META name="keywords" content="joke, music, MP3, media, audio, joke of the day, downloads, free music, horoscope, radio, video, music downloads, movies, radio station, media player, free, download, weather, horoscopes, windows media technologies, online, radio station guide, free download">  
　　 小资源 : 人们最常用的一些搜索词 ( 即关键词  可以到  
http://www.searchterms.com/   
http://eyescream.com/yahootop200.html   
　　 两个网址一看，那里有每个月网上最流行搜索词的排行榜 .  
　　 另外为了提高搜索点击率，这里还有一些"邪门歪道"：  
　　 1. 为了增加关键词的密度，将关键字隐藏在页面里 ( 将文字颜色定义成与背景颜色一样  。  
　　 2. 在图象的 alt 注释语句中加入关键字。 如： < IMG SRC="xxx.gif" Alt="keywords">  
　　 3. 利用 HTML 的注释语句，在页面代码里加入大量关键字。 用法： < !--- 这里插入关键字 --->

 [转载]

C# Code Test:

public class Class1
{
 static void Main(string[] args)
 {
 // string regex = @"^((\d{2}(([02468][048])|([13579][26]))[\-\/\s]?((((0?[13578])|(1[02]))[\-\/\s]?((0?[1-9])|([1-2][0-9])|(3[01])))|(((0?[469])|(11))[\-\/\s]?((0?[1-9])|([1-2][0-9])|(30)))|(0?2[\-\/\s]?((0?[1-9])|([1-2][0-9])))))|(\d{2}(([02468][1235679])|([13579][01345789]))[\-\/\s]?((((0?[13578])|(1[02]))[\-\/\s]?((0?[1-9])|([1-2][0-9])|(3[01])))|(((0?[469])|(11))[\-\/\s]?((0?[1-9])|([1-2][0-9])|(30)))|(0?2[\-\/\s]?((0?[1-9])|(1[0-9])|(2[0-8]))))))(\s(((0?[0-9])|([1-2][0-3]))\:([0-5]?[0-9])((\s)|(\:([0-5]?[0-9])))))?$";
  string regex = @"^((\d{2}(([02468][048])|([13579][26]))[\-\/\s]?((((0?[13578]
)|(1[02]))[\-\/\s]?((0?[1-9])|([1-2][0-9])|(3[01])))|(((0?[4
69])|(11))[\-\/\s]?((0?[1-9])|([1-2][0-9])|(30)))|(0?2[\-\/\
s]?((0?[1-9])|([1-2][0-9])))))|(\d{2}(([02468][1235679])|([1
3579][01345789]))[\-\/\s]?((((0?[13578])|(1[02]))[\-\/\s]?((
0?[1-9])|([1-2][0-9])|(3[01])))|(((0?[469])|(11))[\-\/\s]?((
0?[1-9])|([1-2][0-9])|(30)))|(0?2[\-\/\s]?((0?[1-9])|(1[0-9]
)|(2[0-8]))))))"; //日期部分
  regex += @"(\s(((0?[0-9])|([1-2][0-3]))\:([0-5]?[0-9])((\s)|(\:([0-5]?[0-9])))))?$"; //时间部分
  System.Text.RegularExpressions.RegexOptions options = ((System.Text.RegularExpressions.RegexOptions.IgnorePatternWhitespace | System.Text.RegularExpressions.RegexOptions.Multiline) | System.Text.RegularExpressions.RegexOptions.IgnoreCase);
  System.Text.RegularExpressions.Regex reg = new System.Text.RegularExpressions.Regex(regex, options);

  string s = "2003-02-29 23:59:59";
  System.Console.Out.WriteLine(s + " {0}",reg.IsMatch(s));
  
  s = "2004-02-29 23:59:59";
  System.Console.Out.WriteLine(s + " {0}",reg.IsMatch(s));
  
  s = "2004-04-30 0:59:59";
  System.Console.Out.WriteLine(s + " {0}",reg.IsMatch(s));

  s = "2004-04-30 01:11:0";
  System.Console.Out.WriteLine(s + " {0}",reg.IsMatch(s));

  s = "2004-04-30 0:0:0";
  System.Console.Out.WriteLine(s + " {0}",reg.IsMatch(s));

  s = "2004-04-30 00:00:00";
  System.Console.Out.WriteLine(s + " {0}",reg.IsMatch(s));
 }
}

//Java Code Test

import java.util.regex.*;
class Class1
{
 public static void main(String[] args)
 {
  Pattern p = Pattern.compile("^((\\d{2}(([02468][048])|([13579][26]))[\\-\\/\\s]?((((0?[13578])|(1[02]))[\\-\\/\\s]?((0?[1-9])|([1-2][0-9])|(3[01])))|(((0?[469])|(11))[\\-\\/\\s]?((0?[1-9])|([1-2][0-9])|(30)))|(0?2[\\-\\/\\s]?((0?[1-9])|([1-2][0-9])))))|(\\d{2}(([02468][1235679])|([13579][01345789]))[\\-\\/\\s]?((((0?[13578])|(1[02]))[\\-\\/\\s]?((0?[1-9])|([1-2][0-9])|(3[01])))|(((0?[469])|(11))[\\-\\/\\s]?((0?[1-9])|([1-2][0-9])|(30)))|(0?2[\\-\\/\\s]?((0?[1-9])|(1[0-9])|(2[0-8]))))))(\\s(((0?[0-9])|([1-2][0-3]))\\:([0-5]?[0-9])((\\s)|(\\:([0-5]?[0-9])))))?$");

  String s = "2003-02-29 23:59:59";
  System.out.println(s + " " + p.matcher(s).matches());

  s = "2004-02-29 23:59:59";
  System.out.println(s + " " + p.matcher(s).matches());

  s = "2004-04-31 0:59:59";
  System.out.println(s + " " + p.matcher(s).matches());

  s = "2004-04-30 01:11:0";
  System.out.println(s + " " + p.matcher(s).matches());

  s = "2004-04-30 0:0:0";
  System.out.println(s + " " + p.matcher(s).matches());

  s = "2004-04-30 00:00:59";
  System.out.println(s + " " + p.matcher(s).matches());
 }
}

asp.net操作Excel是B/S架构开发报表中经常遇到的,现对常见操作总结如下:　
以下来自孟子e章

DataGrid输出到Excel并进行格式化处理
用Xml2OleDb将XML文件插入到数据库
在C#中利用Excel做高级报表
在ASP.NET中将数据直接输出成Excel内容
在.NET环境下将报表导出Excel和Word
将DataGrid输出到Excel文件
把Excel文件中的数据读入到DataGrid中


Other

关于asp.net导出Excel
http://www.cnblogs.com/caizinet/archive/2005/05/11/152908.aspx

ASP.NET & Excel
http://www.cnblogs.com/birdshome/favorite/1666.html

如何使用 ASP.NET、ADO.NET 和 Visual C# .NET 查询和显示 Excel 数据
http://support.microsoft.com/default.aspx?scid=kb;zh-cn;306572

必学:将Asp.Net页面输出到EXCEL里去
http://blog.edu.cn/user1/18141/archives/2005/198690.shtml

ASP.NET中数据库数据导入Excel并打印
http://www.weste.net/2004/12-20/11440068743.html

Microsoft Excel for Data Analysis and Reporting in ASP.NET
http://www.asp101.com/articles/jayram/exceldotnet/default.asp

在ASP.NET下用Microsoft Excel进行数据分析与报表
http://dev.csdn.net/develop/article/20/20283.shtm

如何在ASP.NET中用OWC绘制图表
http://tech.ccidnet.com/pub/article/c1111_a65936_p1.html

Export data to Excel by using an HTTPHandler, XSLT, and ASP.NET
http://www.kbalertz.com/kb_871040.aspx

在asp.net访问Excel文件
http://www.chinacs.net/archives/2/2001/06/29/361.html

Using Office Web Components to Load Excel Workbooks and do Calculations
http://www.eggheadcafe.com/articles/20030725.asp

Link ASP.NET Data Grid to Microsoft Excel in the client side
http://www.codeproject.com/aspnet/DGExdel.asp

Create your ASP & ASP.NET-pages using Excel
http://www.exceleverywhere.com/excel-asp-net.htm

Exporting to Excel in Crystal Reports .NET
http://aspalliance.com/478

Create Dynamic ASP.NET Excel Workbooks In C#
http://www.eggheadcafe.com/articles/20021012.asp

ASP.NET中数据库数据导入Excel并打印
http://www.chinacs.net/archives/2/2005/01/28/195.html

将Asp.Net页面输出到EXCEL里去
http://www.pconline.com.cn/pcedu/empolder/net/0412/513965.html

关于asp.net导出Excel
http://www.cnblogs.com/caizinet/archive/2005/05/11/152908.aspx


特别推荐：纯VB.NET代码直接生成Excel文件（不需要Excel）
http://unruledboy.cnblogs.com/archive/2004/07/07/22093.html

/*

========================================

清除应用程序进程，这里是Excel进程

========================================

*/

  private void KillExcelProceed()
  {
   int ProceedingCount = 0;
   System.Diagnostics.Process[] ExcelProcesses;
   ExcelProcesses = System.Diagnostics.Process.GetProcessesByName("EXCEL");

   foreach(System.Diagnostics.Process IsProcedding in ExcelProcesses)
   {
    if(IsProcedding.ProcessName=="EXCEL")
    {
     ProceedingCount += 1;
    }
   }
   if(ProceedingCount > 0)
   {
    DialogResult result;
    result=MessageBox.Show("发现系统中有Excel进程，要关闭所有Excel进程吗？","提示",MessageBoxButtons.YesNo,MessageBoxIcon.Information);
    
    if(result==DialogResult.Yes)
    {
     foreach(System.Diagnostics.Process myProcess in ExcelProcesses)
     {
            myProcess.Kill();

     }
    }
   }

  }

注意，该段代码将搜索所有的Excel进程并关闭。

/*

==================================

另外的一种不是很成熟的方法，来关掉一个Excel进程

这个方法思路有了，但是还并不能真正的实现

==================================

*/

 Excel.Application xlsApp = null;
 Excel._Workbook xlsBook = null;
 Excel._Worksheet xlsSheet = null;
 Excel.Range range = null;

         try
         {
              xlsApp = new Excel.Application();
      xlsBook = (Excel._Workbook)xlsApp.Workbooks.Add();
              xlsSheet = (Excel._Worksheet)xlsBook.Worksheets.get_Item(1);
             
              ...........

              xlsBook.SaveAs(exportpath);    
    
      xlsBook.Close(false);
      xlsApp.Workbooks.Close();
      xlsApp.Quit();
   
              System.Runtime.InteropServices.Marshal.ReleaseComObject(range);
              System.Runtime.InteropServices.Marshal.ReleaseComObject(xlsSheet);
      System.Runtime.InteropServices.Marshal.ReleaseComObject(xlsBook );
              System.Runtime.InteropServices.Marshal.ReleaseComObject(xlsApp);

      range = null;
      xlsSheet = null;
      xlsBook = null;
      xlsApp = null;

              GC.Collect();    
         }
         catch
 {
       xlsBook.Close(false);
       xlsApp.Workbooks.Close();
       xlsApp.Quit();

               System.Runtime.InteropServices.Marshal.ReleaseComObject(range);
               System.Runtime.InteropServices.Marshal.ReleaseComObject(xlsSheet);
       System.Runtime.InteropServices.Marshal.ReleaseComObject(xlsBook );
               System.Runtime.InteropServices.Marshal.ReleaseComObject(xlsApp);

       range = null;
       xlsSheet = null;
       xlsBook = null;
       xlsApp = null;
            
                GC.Collect();
         }

以下为在网上摘抄过来的文章，经过试验大部分可用，但是仍然有少部分不能在SQL 中发挥作用，由于时间关系，暂时不能对其做出修改，唯有先搁置在此，等有时间的时候再来慢慢研究

——————————————————————————————————————————

最近我在为公司的框架程序（以数据应用为导向的应用体系）做数据管理模块，这个模块的需求比较简单：备份、恢复和清理日志。我公司的软件基本上以C/S为基本架构，所以数据管理模块中两个主要的功能‘备份与恢复’都可能会在Client端操作，备份与恢复’的文件也都有可能存储在client端，因而这个数据管理模块就必须能够实现在远程备份与恢复数据库。

文章的前提阐述完了，就该说说如何具体实

最近我在为公司的框架程序（以数据应用为导向的应用体系）做数据管理模块，这个模块的需求比较简单：备份、恢复和清理日志。我公司的软件基本上以C/S为基本架构，所以数据管理模块中两个主要的功能‘备份与恢复’都可能会在Client端操作，备份与恢复’的文件也都有可能存储在client端，因而这个数据管理模块就必须能够实现在远程备份与恢复数据库。

文章的前提阐述完了，就该说说如何具体实现吧。其实都很简单，我想写个远程备份的测试实例
给大家看,就能够很清楚的描述吧！
实例说明：
环境：win2k+sqlserver 2K+查询分析器
SQLSERVER服务实例名称:mainserver
需要备份的数据库名称: msdb
本地机器名称（Client端）：david
本地用户:zf 密码：123
本地域名：domain
本地提供备份需求的文件夹:e:\test

第一步: 建立共享文件夹
在程序代码中调用（或者CMD窗口） net share test=e:\test
或者用NetShareAdd这个API
简要说明：
net share : 是WINDOWS内部的网络命令。
作用：建立本地的共享资源，显示当前计算机的共享资源信息。
语法：参见 net share /?
第二步: 建立共享信用关系
master..xp_cmdshell ’net use \\david\test 123 /user:domain\zf’
简要说明：
1：xp_cmdshell ：是SQLSERVER的扩展存储过程。
作用，以操作系统命令行解释器的方式执行给定的命令字符串，
并以文本行方式返回任何输出。
语法：参见SQLSERVER联机帮助
2:net use : 是WINDOWS内部的网络命令。
作用，将计算机与共享资源连接或断开，或者显示关于计算机
连接的信息。该命令还控制持久网络连接。
语法：参见 net use /?

第三步:备份数据库
backup database msdb to disk=’\\david\test\msdb.bak’
这个不需要说明吧，语法参见SQLSERVER联机帮助

第四步: 删除共享文件夹
在程序代码中调用（或者CMD窗口） net share test /delete
或者用NetShareDel这个API
结果:
已处理 1376 页，这些页属于数据库 ’msdb’ 的文件 ’MSDBData’（位于文件 1 上）。
已处理 1 页，这些页属于数据库 ’msdb’ 的文件 ’MSDBLog’（位于文件 1 上）。
BACKUP DATABASE 操作成功地处理了 1377 页，花费了 3.653 秒（3.086 MB/秒）。

这样mainserver服务器上的msdb就备份到了david机器的E:\test\msdb.bak文件了，使用起来很简单吧？恢复数据库操作也是一样，只要将第三个步骤的语句改为’restore database msdb from disk=’\\david\test\msdb.bak’就可以啦。。你看完了也可以试试呀？！（最简单的测试工具查询分析器+CMD窗口）

备注：xp_cmdshell 这个扩展存储过程只能SA级别的用户调用，而且是SQLSERVER的安全隐患之一，许多DBA都喜欢将其删除或者禁用，所以开发人员使用时要倍加小心哦。
文章中的例子只是简要的说明了应如何利用扩展存储过程实现远程备份与恢复，没有涉及安全以及其他方面的考虑，希望读者在代码中自行完善。

文章引用地址：

   http://info.qinghuaonline.com/info/info_9_arc26257.htm