IDENT_CURRENT 返回为任何会话和任何作用域中的特定表最后生成的标识值。IDENT_CURRENT 不受作用域和会话的限制，而受限于指定的表。IDENT_CURRENT 返回为任何会话和作用域中的特定表所生成的值。
@@IDENTITY 返回为当前会话的所有作用域中的任何表最后生成的标识值。
SCOPE_IDENTITY 返回为当前会话和当前作用域中的任何表最后生成的标识值

SCOPE_IDENTITY 和 @@IDENTITY 返回在当前会话中的任何表内所生成的最后一个标识值。但是，SCOPE_IDENTITY 只返回插入到当前作用域中的值；@@IDENTITY 不受限于特定的作用域。

例如，有两个表 T1 和 T2，在 T1 上定义了一个 INSERT 触发器。当将某行插入 T1 时，触发器被激发，并在 T2 中插入一行。此例说明了两个作用域：一个是在 T1 上的插入，另一个是作为触发器的结果在 T2 上的插入。

假设 T1 和 T2 都有 IDENTITY 列，@@IDENTITY 和 SCOPE_IDENTITY 将在 T1 上的 INSERT 语句的最后返回不同的值。

@@IDENTITY 返回插入到当前会话中任何作用域内的最后一个 IDENTITY 列值，该值是插入 T2 中的值。

SCOPE_IDENTITY() 返回插入 T1 中的 IDENTITY 值，该值是发生在相同作用域中的最后一个 INSERT。如果在作用域中发生插入语句到标识列之前唤醒调用 SCOPE_IDENTITY() 函数，则该函数将返回 NULL 值。

而IDENT_CURRENT('T1') 和 IDENT_CURRENT('T2') 返回的值分别是这两个表最后自增的值。

ajqc的实验:(40条本地线程,40+40条远程线程同时并发测试,插入1200W行),得出的结论是:
1.在典型的级联应用中.不能用@@IDENTITY,在CII850,256M SD的机器上1W多行时就会并发冲突.在P42.8C,512M DDR上,才6000多行时就并发冲突.
2.SCOPE_IDENTITY()是绝对可靠的,可以用在存储过程中,连触发器也不用建,没并发冲突

SELECT   IDENT_CURRENT('TableName')   --返回指定表中生成的最后一个标示值   
SELECT   IDENT_INCR('TableName')--返回指定表的标示字段增量值
SELECT   IDENT_SEED('TableName')--返回指定表的标示字段种子值

返回最后插入记录的自动编号
SELECT IDENT_CURRENT('TableName')
 返回下一个自动编号:   
 SELECT   IDENT_CURRENT('TableName')   +   (SELECT   IDENT_INCR('TableName'))

SELECT @@IDENTITY --返回当前会话所有表中生成的最后一个标示值

前几天在做项目时，遇到插入数据的同时，返回ID值的问题，遂记录如下：

      插入数据的同时，返回ID值的sql语句。

      MSSQL:

           INSERT INTO test2 (aa)   VALUES ('cc')   SELECT @@IDENTITY AS SEQUENCE

       MYSQL:

          select last_insert_id() as ID from T_D_NM_SHOP_TEMPLET limit 1

        在ibatis中，可以这样配置：

      <!--创建任务MYSQL数据库，在MYSQL数据库中，表T_D_QT_TASK中的task_id为自增字段。-->
     <!--在插入数据，返回task_id的插入值的配置文件如下-->
    <parameterMap id="MapTask" class="java.util.HashMap">
    <parameter property="taskgroup_id" jdbcType="varchar"
   javaType="java.lang.Integer" mode="IN" />
   <parameter property="task_name" jdbcType="varchar"
   javaType="java.lang.String" mode="IN" />
  <parameter property="task_content" jdbcType="varchar"
   javaType="java.lang.String" mode="IN" />
  <parameter property="test_object" jdbcType="varchar"
   javaType="java.lang.String" mode="IN" />
  <parameter property="status" jdbcType="varchar"
   javaType="java.lang.Integer" mode="IN" />
  <parameter property="user_id" jdbcType="varchar"
   javaType="java.lang.String" mode="IN" />
  <parameter property="script_type" jdbcType="varchar"
   javaType="java.lang.String" mode="IN" />
 </parameterMap>
 <insert id="insertTask" parameterMap="MapTask">
  insert into T_D_QT_TASK (`TASKGROUP_ID` ,`TASK_NAME`
  ,`TASK_CONTENT` , `TEST_OBJECT` ,`PRIORITY`,`STATUS`, `USER_ID`
  ,`SCRIPT_TYPE` ) values(?,?,?,?,'9',?,?,?)
  <selectKey resultClass="java.lang.String" keyProperty="tid">
   select last_insert_id() as TASK_ID from T_D_QT_TASK limit 1
  </selectKey>
 </insert>
<!--创建任务ORACLE数据库, 在oracle数据库中，表T_D_QT_TASK中的task_id没有设置为自增。-->
<!--（这样设置我得到的主键返回值总是大于实际插入值）,遂取消task_id与触发器的关联。-->
<!--直接建立一个SEQ：SEQ_D_QT_TASK获取它的返回值，直接插入到表中 .注意配置-->
<!--中的keyProperty="task_id"。是把seq的返回值，放入到对应的映射中的task_id中-->
 <parameterMap id="MapTask" class="java.util.HashMap">
  <parameter property="task_id" jdbcType="varchar"
   javaType="java.lang.Integer" mode="IN" />
  <parameter property="taskgroup_id" jdbcType="varchar"
   javaType="java.lang.Integer" mode="IN" />
  <parameter property="task_name" jdbcType="varchar"
   javaType="java.lang.String" mode="IN" />
  <parameter property="task_content" jdbcType="varchar"
   javaType="java.lang.String" mode="IN" />
  <parameter property="test_object" jdbcType="varchar"
   javaType="java.lang.String" mode="IN" />
  <parameter property="status" jdbcType="varchar"
   javaType="java.lang.Integer" mode="IN" />
  <parameter property="user_id" jdbcType="varchar"
   javaType="java.lang.String" mode="IN" />
  <parameter property="script_type" jdbcType="varchar"
   javaType="java.lang.String" mode="IN" />
 </parameterMap>
 <insert id="insertTask" parameterMap="MapTask">
  <selectKey resultClass="java.lang.Integer"
   keyProperty="task_id">
   SELECT SEQ_D_QT_TASK.NEXTVAL AS ID FROM DUAL
  </selectKey>
  insert into T_D_QT_TASK (TASK_ID,TASKGROUP_ID ,TASK_NAME
  ,TASK_CONTENT , TEST_OBJECT ,PRIORITY,STATUS, USER_ID
  ,SCRIPT_TYPE ) values(?,?,?,?,?,'9',?,?,?)
 </insert>

下。

传说中的方法一：（源于http://topic.csdn.net/t/20050203/10/3772606.html）

47 楼Truly（）回复于 2005-02-03 20:19:58 得分 15

1.iis默认站点－主目录－设置－添加－  
   
  Executable:   C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll  
  Extension:.mspx  
   
  确定  
   
  2.web.config  
      <system.web>  
  <httpHandlers>  
      <add   verb="*"   path="*.mspx"   type="System.Web.UI.PageHandlerFactory"/>  
  </httpHandlers>

传说中的方法二：HttpHandler HttpModule 做出属于自己的后缀的网页 !

 首先谈谈ASP.net的一些参数传递和页面定向的方式
      第一，ASP.net是用Page.Navigate()调用新页面的URL。Page.Navigate()向浏览器返回了一个http状态码302，使得浏览器向server请求那个新的URL。这种导航方法导致每次客户请求都需两次在client和server之间往返。
      第二，任何要传递到新页面的信息都需作为URL的参数或存储在Session中或存储在数据库中以便新页面得到这些信息。传统的ASP开发人员很习惯这种做法，但其他的web编程人员则有一些更高级的方法。但是很明显的这两个页面是有依赖性的，而依赖性是编译器捕捉不到的也是不容易在设计阶段建模的。所以在debug时，参数是否被正确的传递就只有我们自己检查了。再有传统的数据传递方式有可能会暴露一些关键的数据。更为关键的是这使得面向对象的设计变得很复杂。

      但是我们可以自定义httphandler来扩充这种支持。
       要对HTTPMODULE和IHTTPHANDLER进行研究，必须先对ASP.NET的处理管道有一个了解。 
    在ASP.NET应用程序中，系统使用一组相关的类，通过一定的顺序来处理客户端的请求(REQUEST)，ASP.NET应用程序的处理模式可称之为HTTP处理管道。      
    HTTPMODULE和IHTTPHANDLER就是这个处理管道上的两个处理环节。 HTTP处理管道中的类在SYSTEM.WEB名称空间中定义，主要有以下类型： HTTPWORKERREQUEST 抽象类定义了ASP.NET页面处理请求的基本方法； 
   HTTPRutime 提供了处理应用的一组服务； 
   HTTPContext 保存了处理一次请求的所有相关上下文信息； 
   HTTPApplicationFactory 提供相关目录的应用程序； 
   HTTPApplication 定义了所有ASP.NET应用程序的通用的方法、属性和事件。这个类也是在用户在GLOBAL.ASAX文件中定义的应用的基类； 
   Modules 处理请求前和响应后的事件； 
   Handlerfactories 提供应用程序中的HANDLERS； 
   Handlers 处理请求和响应。 

   在WINDOWS平台上，HTTP PIPLINE需要IIS的支持。为了运行ASP.NET应用，IIS需要以下两个文件：ASPNET_ISAPI.DLL和ASPNET_WP.EXE ASPNET_ISAPI.DLL是一个ISAPI EXTENTION他将发向IIS的请转交ASPNET_WP.EXE处理 ASPNET_WP.EXE使用HTTPRUNTIME对请求进行具体处理 处理的过程可以用图表示如下:


     

下面一个简单的例子来理解! 1). 建立一个名为SimpleHandler的工程，添加一个类MyHandler.cs，代码如下：

namespace SimpleHandler
{
    public class MyHandler : IHttpHandler
    {
        public void ProcessRequest(HttpContext ctx)
        {
            HttpResponse response = ctx.Response;
            
           response.Write(" My first Handler !");
        }
        public bool IsReusable
        {
            get { return true; }
        }
    }
}

 2). 将上面的代码编译，生成SimpleHandler.dll 文件；

 3). 建立一个新的Web项目,将文件SimpleHandler.dll 添加到项目的引用中；
 4). 修改Web.config ，添加如下内容: 
   <system.web>
      <httpHandlers>
        <add verb="*" path="*.ASPX" type="SimpleHandler.MyHandler,SimpleHandler" />       
      </httpHandlers>
    </system.web>
   配置文件中的选项说明： 
   VERB可以是"GET"或"POST"，表示对GET或POST的请求进行处理。
   "*"表示对所有请求进行处理。 
   PATH指明对相应的文件进行处理，"*.ASPX"表示对发给所有ASPX页面的请求进行处理。可以指明路径，如"/TEST/*.ASPX"，表明只对TEST目录下的ASPX文件进行处理。 
   TYPE属性中，逗号前的字符串指明HTTPHANDLER的实现类的类名，后面的字符串指明DLL文件的名称。 
   现在，请求项目中的任何ASPX页面，页面上显示的始终只有如下一行字： My first Handler !




因为，我们自定义的HANDLER截获了所有发向ASPX页面的请求，并且用自己的的方法来处理这些请求了。

为了使我们的字定义页面 如: *.AAA 能够顺利运行，我们需要修改WEB.CONFIG文件： 
 
     <system.web>
            <httpHandlers>
                 <add verb="*" path="*.AAA" type="SimpleHandler.MyHandler,SimpleHandler" />        
            </httpHandlers>
    </system.web>
为了让对后缀名为.AAA 的文件的请求能够被我们的HANDLER截获运行，我们还需要一些额外的工作。打开IIS的管理控制台，又键单击站点，选择"属性"，跳出站点的属性对话框。选择主目录选项,选择配置，弹出应用程序配置对话框，将".AAA"添加到应用程序映射中 . 好了，我们现在可以在项目中添加一个.AAA 文件，当向该文件发送请求时，浏览器显示：  My first Handler !   而对其他ASPX文件的访问不受影响。

Configuration settings for any of your ASP.NET Web applications can be stored in a simple text file. Presented in an easily understandable XML format, this file, called Web.config, can contain application-wide data such as database connection strings, custom error messages, and culture settings.

Because the Web.config is an XML file, it can consist of any valid XML tags, but the root element should always be <configuration>. Nested within this tag you can include various other tags to describe your settings. Since a Web.config file comes as a standard when you start to build a new Web application, let's look at the default XML file generated by Visual Studio .NET:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <system.web>
   <compilation  
        defaultLanguage="c#"
        debug="true"
   />
   <customErrors  
   mode="RemoteOnly"  
   />  
   <authentication mode="Windows" />  
   <authorization>
       <allow users="*" />
   </authorization>
   <trace
       enabled="false"
       requestLimit="10"
       pageOutput="false"
       traceMode="SortByTime"
   localOnly="true"
   />
   <sessionState  
           mode="InProc"
           stateConnectionString="tcpip=127.0.0.1:42424"
           sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
           cookieless="false"  
           timeout="20"  
   />
   <globalization  
           requestEncoding="utf-8"  
           responseEncoding="utf-8"  
  />
   
</system.web>

</configuration>

Experienced ASP.NET programmers will have noticed that I've left out the comment tags that are generated automatically with the file. I've done that to provide a clear view of the XML that's used here. Also, I'll elaborate on each configuration tag later in this article, and this discussion will make the comment tags rather obsolete.

If you look at the example XML, you'll notice that the <configuration> tag has only one child tag, which we call section group, the <system.web> tag. A section group typically contains the setting sections, such as: compilation, customErrors, authentication, authorization, etc. The way this works is pretty straightforward: you simply include your settings in the appropriate setting sections. If, for example, you wanted to use a different authentication mode for your Web application, you'd change that setting in the authentication section.

Apart from the standard system.web settings, you can define your own specific application settings, such as a database connection string, using the <appSettings> tag. Consequently, your most common Web.config outline would be:

<configuration>
 <system.web>
   <!— sections-->    
 </system.web>
 <appSettings>
   <!— sections -->    
 </appSettings >
</configuration>

Let's discuss the details of both section groups now.

The system.web Section Group

In this section group, you'll typically include configuration settings that, in the pre-.NET era, you'd have set up somewhere in the IIS administration console. At Microsoft's MSDN Library, you can find an overview of all the tags that the system.web section group understands, but, depending on the complexity of your site, you may not ever use even half of those options.

Let's have a look at the most valuable tweaks you can make within the system.web section group, in alphabetical order.

<authentication>

The authentication section controls the type of authentication used within your Web application, as contained in the attribute mode. You'll enter the value "None" if anyone may access your application. If authentication is required, you'll use "Windows", "Forms" or "Passport" to define the type of authentication. For example:

   <authentication mode="Windows" />

<authorization>

To allow or deny access to your web application to certain users or roles, use <allow> or <deny> child tags.

   <authorization>
       <allow roles="Administrators,Users" />
       <deny users="*" />
   </authorization>

It's important to understand that ASP.NET's authorization module iterates through the sections, applying the first rule that corresponds to the current user. In this example, users carrying the role Administrators or Users will be allowed access, while all others (indicated by the * wildcard) will encounter the second rule and will subsequently be denied access.

<compilation>

Here, you can configure the compiler settings for ASP.NET. You can use loads of attributes here, of which the most common are debug and defaultLanguage. Set debug to "true" only if you want the browser to display debugging information. Since turning on this option reduces performance, you'd normally want to set it to "false". The defaultLanguage attribute tells ASP.NET which language compiler to use, since you could use either Visual Basic .NET or C# for instance. It has value vb by default.

<customErrors>

To provide your end users with custom, user-friendly error messages, you can set the mode attribute of this section to On. If you set it to RemoteOnly, custom errors will be shown only to remote clients, while local host users will see the ugly but useful ASP.NET errors -- clearly, this is helpful when debugging. Setting the mode attribute to Off will show ASP.NET errors to all users.

If you supply a relative (for instance, /error404.html) or absolute address (http://yourdomain.com/error404.html) in the defaultRedirect attribute, the application will be automatically redirected to this address in case of an error. Note that the relative address is relative to the location of the Web.config file, not the page in which the error takes place. In addition you can use <error> tags to provide a statusCode and a redirect attribute:

   <customErrors mode="RemoteOnly" defaultRedirect="/error.html">
       <error statusCode="403" redirect="/accessdenied.html" />
       <error statusCode="404" redirect="/pagenotfound.html" />
   </customErrors>

<globalization>

The globalization section is useful when you want to change the encoding or the culture of your application. Globalization is such an extensive subject that an entire article could be dedicated to the matter. In short, this section allows you to define which character set the server should use to send data to the client (for instance UTF-8, which is the default), and which settings the server should use to interpret and displaying culturally specific strings, such as numbers and dates.

   <globalization requestEncoding="utf-8" responseEncoding="utf-8"  
       culture="nl-NL" />

Encoding is done through the attributes requestEncoding and responseEncoding. The values should be equal in all one-server environments. In this example, the application culture is set to Dutch. If you don't supply a culture, the application will use the server's regional settings.

<httpRuntime>

You can use the httpRuntime section to configure a number of general runtime settings, two of which are particularly convenient.

   <httpRuntime appRequestQueueLimit="100" executionTimeout="600" />

The first attribute specifies the number of requests the server may queue in memory at heavy-traffic times. In the example, if there are already 100 requests waiting to be processed, the next request will result in a 503 error ("Server too busy").

The executionTimeout attribute indicates the number of seconds for which ASP.NET may process a request before it's timed out.

<sessionState>

In this section of the Web.config file, we tell ASP.NET where to store the session state. The default is in the process self:

   <sessionState mode="InProc" />

Session variables are very powerful, but they have a few downsides. Information is lost when the ASP.NET process crashes, and sessions are generally useless in the case of a Web farm (multiple Web servers). In that instance, a shared session server can solve your issues. It's beyond the scope of this article to expand on this topic, but it's worth a mention. More information on sessionState can be found in the MSDN Library online.

<trace>

Your application's trace log is located in the application root folder, under the name trace.axd. You can change the display of tracing information in the trace section.

The attributes you will look for initially are enabled: localOnly, and pageOutput.

   <trace enabled="true" localOnly="true" pageOutput="false" />

Set localOnly to "false" to access the trace log from any client. If you set the value of pageOutput to "true", tracing information will be added to the bottom of each Web page.

The appSettings Section Group

Apart from the Website configuration settings I've been talking about in the preceding paragraphs, you'll know that a programmer frequently likes to use custom application-wide constants to store information over multiple pages. The most appealing example of such a custom constant is a database connection string, but you can probably think of dozens more from your own experience.

The common denominator of these constants is that you want to retrieve their values programmatically from your code. The Web.config file provides the possibility to do so, but as a security measure, these constants have to be included in the <appSettings> section group. Just like <system.web>, <appSettings> is a direct child tag of the Web.config's configuration root.

A typical custom section group would look something like this:

   <appSettings>
       <add key="sqlConn" value="Server=myPc;Database=Northwind" />
       <add key="smtpServer" value="smtp.mydomain.com" />
   </appSettings>

The example shows that keys and values can be included in the custom application settings via an <add> tag. The way to access such a value in any of your Web pages is illustrated below:

   ConfigurationSettings.AppSettings["sqlConn"]

Yes, it's as easy as that! Note that the value of these settings is always a String format.

A Few Other Issues

I won't go into them here, but the Web.config file can contain several other section groups besides the aforementioned system.web and appSettings, such as the configSettings group.

• A Web application can contain more than one Web.config file. The settings in a file apply to the directory in which it's located, and all child directories. Web.config files in child directories take precedence over the settings that are specified in parent directories.
• Web.config files are protected by IIS, so clients cannot get to them. If you try to retrieve an existing http://mydomain.com/Web.config file, you'll be presented with an "Access denied" error message.
• IIS monitors the Web.config files for changes and caches the contents for performance reasons. There's no need to restart the Web server after you modify a Web.config file.

Closing Remarks

In this article, I've touched upon the possibilities that the Web.config file offers the ASP.NET programmer. You can use the easily accessible XML file to define your application settings, without the hassle of using the IIS management console. With the Web.config file, ASP.NET lets you add, change and delete basic configuration settings like authentication and authorization, custom error displaying, and tracing in a straightforward manner.

Moreover, the Web.config file offers you room to define any custom key you require, such as database connection strings. What we've subsequently seen is that, with just one line of code, you can retrieve the information you need from any page in your application.