两种修改形式
第一种：静态插入
1 update #famousjaycess set jc=‘johnny cash‘,occupation=‘Singer/songwriter‘,becamefamous=1955,notes=‘began career selling ...balabala‘ 2 where jc=‘johnny ca‘
第二种：
1 --注意别名和on后边的表连接不要写错 2 update f set jc=‘johnny cash‘,occupation=‘Singer/songwriter‘,becamefamous=1955,notes=‘began career selling ...balabala‘ 3 from #famousjaycess f 4 join #samefamousjaycess s on (f.becamefamous=s.becamefamous)
Halloween的问题
在修改过程中，将被修改行在将被修改的行的列表中移动，会引起多次被修改，这种情况被称为Halloween问题。
好在在问题发生时sql会认识到这个问题，以及那种类型的错误，然后采取措施。
将主关键字和触发器结合起来，看上去好像会增加问题的可能性，毕竟触发器认为数据时被修改的；而实际情况是sqlserver的触发器每个语句只会执行一次，而不是每行都被触发一次
并且触发器只在数据修改之前或之后进行存取，并不是在过程中进行存取。看上去仿佛并没有什么用，但其实并不是。触发器的代码并不会和触发他们的insert、delete、update命令一起编译
执行计划。而是独立的编译并放入缓冲区，所以无论触发它的命令是什么，都可以有效的重复使用。DML语句的执行计划分支给它激发的所有触发器，这种操作在执行计划结束之前进行的。如果
是结束后就无法完成了。
注意这种情况并不适用于约束。每个表的约束都是直接加入DML的执行计划中。
Update和Case
通过Update使用CASE表达式，可以对表进行比较复杂的操作，但需要一定的编程逻辑。
1 update titles 2 set price=price*case title when ‘business‘ then 1.5 3 when ‘mod_cook‘ then .8 4 when ‘trad_cook‘ then .6 5 when ‘paycholoy‘ then .5 6 when ‘popular_comp‘ then 1.8 7 else .75 8 end
用Update做检测约束
如果使用Bulk Insert或者其他大批量的加载数据的工具来对有insert触发器的表进行追加数据，那么会发现触发器是能被触发。而且，即使Bulk Insert不妨碍约束，也会是操作变得非常慢。
如果在载入时忽略约束，那么就快多了。有一个选项可以在载入数据之后人工的检查约束和触发器。这就要求对于每一个约束和触发器都有单独的代码，并且做大量的防止出错的操作。
另外一种方式就是在数据载入后立刻执行一个假的update操作。这个假的修改只是简单的将列值置为其本身的值。这样就会触发触发器并对约束进行检查。如果其中包含错误的行那么就会update失败。
1 create table famousjaycess( 2 jc varchar(15) check(left(jc,3)<>‘joe‘), 3 occupation varchar(25), 4 becamefamous int default 0, 5 notes text null 6 ) 7 8 9 bulk insert famousjaycess from ‘D:\DB\famousjaycess.bcp‘ 10 11 update famousjaycess set 12 jc=jc, 13 occupation=occupation, 14 becamefamous=becamefamous, 15 notes=notes
限制受update影响的行的数目
用select top n的语句可以限制受影响行的数目。select语句作为导出表嵌入在update的from子句中，并与目标表进行连接
update a set a.contract=0 from authors a join(select top 5 au_id from authors order by au_id) u on a.au_id=u.au_id
