SQL Server 事务语法

事务全部是关于原子性的。原子性的概念是指可以把一些事情当做一个单元来看待。从数据库的角度看,它是指应全部执行或全部都不执行的一条或多条语句的最小组合。 为了理解事务的概念,需要能够定义非常明确的边界。事务要有非常明确的开始和结束点。SQL Server中的每一条SELECT、INSERT、UPDATE和DELETE语句都是隐式事务的一部分。即使只发出一条语句,也会把这条语句当做一个事务-要么执行语句中的所有内容,要么什么都不执行。但是如果需要的不只是一条,可能是多条语句呢?在这种情况下,就需要有一种方法来标记事务的开始和结束,以及事务的成功或失败。可以使用一些T-SQL语句在事务中"标记"这些点。

  • BEGIN TRAN:设置起始点。
  • COMMIT TRAN:使事务成为数据库中永久的、不可逆转的一部分。
  • ROLLBACK TRAN:本质上说想要忘记它曾经发生过。
  • SAVE TRAN:创建一个特定标记符,只允许部分回滚。

一、BEGIN TRAN

  事务的开始可能是事务过程中最容易理解的概念。它唯一的目的就是表示一个单元的开始。如果由于某种原因,不能或者不想提交事务,那么这就是所有数据库活动将要回滚的起点。也就是说,数据库会忽略这个起点之后的最终没有提交的所有语句。

  语法如下:

  BEGIN TRAN[SACTION] [ <transaction name> | <@transaction variable> ]
  [ WITH MARK [<‘description‘>] ]

二、COMMIT TRAN

  事务的提交是一个事务的终点。当发出COMMIT TRAN命令时,可以认为该事务是持久的。也就是说,事务的影响现在是持久的并会持续,即使发生系统故障也不受影响(只要有备份或者数据库文件没有被物理破坏就行)。撤销已完成事务的唯一方法是发出一个新的事务。从功能上而言,该事务是对第一个事务的反转。

  COMMIT TRAN语法如下:

  COMMIT TRAN[SACTION] [<transaction name> | <@transaction variable>]

三、ROLLBACK TRAN

  ROLLBACK做的事情是回到起点。从关联的BEGIN语句开始发生的任何事情事实上都会被忘记。

  除了允许保存点外,ROLLBACK的语法看上去和BEGIN或COMMIT语句一样:

  ROLLBACK TRAN[SACTION] [ <transaction name> | <save point name> | <@transaction variable> | <@savepoint variable> ]

四、SAVE TRAN

  保存事务从本质上说就是创建书签(bookmark)。为书签建立一个名称,在建立了"书签"之后,可以在回滚中引用它。创建书签的好处是可以回滚到代码中的特定点上-只要为想要回滚到的那个保存点命名。

  语法如下:

  SAVE TRAN[SCATION] [ <save point name> | <@savepoint variable> ]

  下面整个示例,先来建一张表如下:

  

  事务的具体代码:

BEGIN TRAN Tran_Money    --开始事务

DECLARE @tran_error int;
SET @tran_error = 0;
    BEGIN TRY
        UPDATE tb_Money SET MyMoney = MyMoney - 30 WHERE Name = ‘刘备‘;
        SET @tran_error = @tran_error + @@ERROR;
        --测试出错代码,看看刘备的钱减少,关羽的钱是否会增加
        --SET @tran_error = 1;
        UPDATE tb_Money SET MyMoney = MyMoney + 30 WHERE Name = ‘关羽‘;
        SET @tran_error = @tran_error + @@ERROR;
    END TRY

BEGIN CATCH
    PRINT ‘出现异常,错误编号:‘ + convert(varchar,error_number()) + ‘,错误消息:‘ + error_message()
    SET @tran_error = @tran_error + 1
END CATCH

IF(@tran_error > 0)
    BEGIN
        --执行出错,回滚事务
        ROLLBACK TRAN;
        PRINT ‘转账失败,取消交易!‘;
    END
ELSE
    BEGIN
        --没有异常,提交事务
        COMMIT TRAN;
        PRINT ‘转账成功!‘;
    END
时间: 2024-08-11 05:45:53

SQL Server 事务语法的相关文章

SQL Server 事务隔离级别详解

原文:SQL Server 事务隔离级别详解 标签: SQL SEERVER/MSSQL SERVER/SQL/事务隔离级别选项/设计数据库事务级别 SQL 事务隔离级别 概述 隔离级别用于决定如果控制并发用户如何读写数据的操作,同时对性能也有一定的影响作用. 步骤 事务隔离级别通过影响读操作来间接地影响写操作:可以在回话级别上设置事务隔离级别也可以在查询(表级别)级别上设置事务隔离级别.事务隔离级别总共有6个隔离级别:READ UNCOMMITTED(未提交读,读脏),相当于(NOLOCK)R

Sql Server 事务日志

Sql Server事务日志文件是数据库文件的重要组成部分,事务日志主要用来存放数据库的修改记录.数据库为了得到更高的写入效率和性能,同时保证ACID特性,数据在写入时,会将更新先写入事务日志,因为事务日志是连写的,所以写事务会比较快.简单来说,顺序写入时,磁盘的磁头会保持在一定的区域内连续写入,而数据写入数据文件时,有随机性,磁盘的磁头移动消耗的时间要比数据写入日志文件时多. Sql Server对于事务日志文件的管理,是将日志文件在逻辑上分成若干个文件(VLFS),方便管理. 创建一个1M的

如何处理SQL Server事务复制中的大事务操作

如何处理SQL Server事务复制中的大事务操作 事务复制的工作机制 事务复制是由 SQL Server 快照代理.日志读取器代理和分发代理实现的.快照代理准备快照文件(其中包含了已发布表和数据库对象的架构和数据),然后将这些文件存储在快照文件夹中,并在分发服务器中的分发数据库中记录同步作业. 日志读取器代理监视为事务复制配置的每个数据库的事务日志,并将标记为要复制的事务从事务日志复制到分发数据库中,分发数据库的作用相当于一个可靠的存储-转发队列. 分发代理将快照文件夹中的初始快照文件和分发数

SQL Server事务执行一半出错是否自动回滚整个事务 【转】

http://www.2cto.com/database/201308/234728.html SQL Server事务执行一半出错是否自动回滚整个事务 大家都知道SQL Server事务是单个的工作单元.如果某一事务成功,则在该事务中进行的所有数据修改均会提交,成为数据库中的永久组成部分.如果事务遇到错误且必须取消或回滚,则所有数据修改均被清除. 所以是不是说事务出错一定会回滚整个事物呢? 先看几个个例子: --createtable create table testrollback(idi

SQL Server事务日志分析

SQL Server事务日志分析 fn_dblog()和fn_dump_dblog()函数介绍 SQL Server有两个未公开的函数fn_dblog()和fn_dump_dblog()非常有用并且提供的信息量很大.你可以使用这些函数来获取100多列大量的有用信息. fn_dblog()用于分析数据库当前的事务日志文件,它需要两个参数,分别为事务开始LSN和结束LSN,默认为NULL,表示返回事务日志文件的所有日志记录. 例如: SELECT * FROM fn_dblog(null,null)

SQL Server 事务嵌套

原文:SQL Server 事务嵌套 示例代码: DECLARE @TranCounter INT; SET @TranCounter = @@TRANCOUNT; IF @TranCounter > 0 -- Procedure called when there is -- an active transaction. -- Create a savepoint to be able -- to roll back only the work done -- in the procedure

理解Sql Server 事务隔离层级(Transaction Isolation Level)

关于Sql Server 事务隔离级别,百度百科是这样描述的 隔离级别:一个事务必须与由其他事务进行的资源或数据更改相隔离的程度.隔离级别从允许的并发副作用(例如,脏读或虚拟读取)的角度进行描述. 隔离级别共5种: read uncommitted | 0 未提交读read committed | 1 已提交读repeatable read | 2 可重复读serializable | 3 可序列化snapshot 快照(2005版本以后新加) 以下面的图为例,在事务A中会根据条件读取TABLE

SQL Server 事务复制分发到订阅同步慢

原文:SQL Server 事务复制分发到订阅同步慢 最近发现有一个发布经常出现问题,每几天就出错不同步,提示要求初始化.重新调整同步后,复制还是很慢!每天白天未分发的命令就达五六百万条!要解决慢的问题,需要了解从发布数据库到订阅数据库中,有哪些操作,才知道哪个步骤同步缓慢. 这是很久之前自己做的一张图,主要描述发布到分发.分发到订阅中,复制使用了哪些操作,如下图: 发布到分发: 在发布中,复制是使用日志读取器读(sp_replcmds)取发布数据库中的事务日志的,日志读取器是按事务顺序读取的,

SQL Server事务回滚对自增键的影响

SQL Server事务回滚时是删除原先插入导致的自增值,也就是回滚之前你你插入一条数据导致自增键加1,回滚之后还是加1的状态 --如果获取当前操作最后插入的identity列的值:select @@IDENTITY--如果要获取某表的最后的identity列的值:select IDENT_CURRENT('表名') --如果要模拟抛出异常可以用RAISERROR --RAISERROR('错误的描述',错误的严重级别代码,错误的标识,错误的描述中的参数的值(这个可以是多个),一些其它参数) -