锁定提示                                 描述  
HOLDLOCK        将共享锁保留到事务完成，而不是在相应的表、行或数据页不再需要时就立即释放锁。HOLDLOCK        等同于        SERIALIZABLE。        
NOLOCK        不要发出共享锁，并且不要提供排它锁。当此选项生效时，可能会读取未提交的事务或一组在读取中间回滚的页面。有可能发生脏读。仅应用于        SELECT        语句。        
PAGLOCK        在通常使用单个表锁的地方采用页锁。        
READCOMMITTED        用与运行在提交读隔离级别的事务相同的锁语义执行扫描。默认情况下，SQL        Server        2000        在此隔离级别上操作。        
READPAST        跳过锁定行。此选项导致事务跳过由其它事务锁定的行（这些行平常会显示在结果集内），而不是阻塞该事务，使其等待其它事务释放在这些行上的锁。READPAST        锁提示仅适用于运行在提交读隔离级别的事务，并且只在行级锁之后读取。仅适用于        SELECT        语句。        
READUNCOMMITTED        等同于        NOLOCK。        
REPEATABLEREAD        用与运行在可重复读隔离级别的事务相同的锁语义执行扫描。        
ROWLOCK        使用行级锁，而不使用粒度更粗的页级锁和表级锁。        
SERIALIZABLE        用与运行在可串行读隔离级别的事务相同的锁语义执行扫描。等同于        HOLDLOCK。        
TABLOCK        使用表锁代替粒度更细的行级锁或页级锁。在语句结束前，SQL        Server        一直持有该锁。但是，如果同时指定        HOLDLOCK，那么在事务结束之前，锁将被一直持有。        
TABLOCKX        使用表的排它锁。该锁可以防止其它事务读取或更新表，并在语句或事务结束前一直持有。        
UPDLOCK        读取表时使用更新锁，而不使用共享锁，并将锁一直保留到语句或事务的结束。UPDLOCK        的优点是允许您读取数据（不阻塞其它事务）并在以后更新数据，同时确保自从上次读取数据后数据没有被更改。        
XLOCK        使用排它锁并一直保持到由语句处理的所有数据上的事务结束时。可以使用        PAGLOCK        或        TABLOCK        指定该锁，这种情况下排它锁适用于适当级别的粒度

------解决方案--------------------
SQL code
就启明星提出的在SQL Server中使用加锁的问题，我就以前的经验和收集的一些资料简单的提出我自己的一些看法，不知道对启明星是否有所帮助： 
 一般而言，下面是个典型的打开数据库的过程。 
  <% 
 ’游标类型 
 Const adOpenForwardOnly = 0 
 Const adOpenKeyset = 1 
 Const adOpenDynamic = 2 
 Const adOpenStatic = 3 
  
 ’加锁类型 
 Const adLockReadOnly = 1 
 Const adLockPessimistic = 2 
 Const adLockOptimistic = 3 
 Const adLockBatchOptimistic = 4  
 >% 
  
  <% set conn = server.createobject(’adodb.connection’) >% 
  <% set rsmov = server.createobject(’adodb.recordset’) >% 
  <% conn.open ’soc’, ’’, ’’ >% 
  <% rsmov.open sqlmov, conn, adopenkeyset, adlockreadonly >% 
 游标使用时是比较灵活的，它有时用来描述一个记录集，有时又是用来描述当前记录集中某一条记录的指针。游标主要是用来建立一个关系数据库中行/列关系的一种SQL可利用的访问格。与游标有关系的技术术语还有一个叫Bookmark的。如果你选择的游标方式支持Bookmarks。数据库将提供有关记录数目的强大功能。在上面写出的那么多游标方式中，adOpenDynamic是没有太的用处的，虽然它提供实时显示数据库中的记录的所有更新操作的功能，但是因为并不是所有的数据库都支持该游标方式，没有移植性的游标方式对当前错综复杂的数据库来说真是用处不大。在实际的编程中，我相信大家使用得最频繁的是adOpenStatic方式，当然这种方式的缺点是不能够就、实时反应出数据库中内容改变时的状况。如果要想看到数据库被其它用户改变的状况，可使用adOpenKeyse方式（但是它只能够反应出被编辑的改变情况，也就是说不能够反映出新增和删除记录的改变情况。） 
 其实上面的内容大家一般都可以在微软的技术参考资料中找到，下面来说说在使用这些游标 
 方式和加锁方式时要注意到的问题。 
 1。首先要注意到的是这两种方式在混合使用时的问题，就是说你同时设置游标方式和加锁方式。 
 除非你是在使用Access数据库，一般而言当你混合使用时是并不能够得到你预期想要的游标方式和加锁方式的。例如，如果你同时将游标设置为adOpenStatic方式，而将加锁设置为adLockOptimistic，你将得不到adOpenStatic方式的游标，你这时使用的游标方式将是 
 adOpenKeyset，也就是说你使用ADO的话，它将返回adOpenKeyset的游标。 
 2。其次，游标和加锁的混合使用还会导致ADO返回的不是你想要的加锁方式，ADO会改变你的加锁 
 方式。例如，在默认状态下游标方式是adOpenForwardOnly，在使用这种游标方式的同时如果 
 你使用的加锁方式为-1（就是让数据源来判断加锁方式）或则adLockReadOnly，那么这种混合方式基本上不支持RecordSet的任何方法，也就是说RecordSet的任何方法将返回False 
 (你的recordcount,absoultpage,addnew,delete,update等都会返回-1，-1就是表示不支持该属性)，但是这时如果你使用的是adOpenForwardOnly游标方式和其它的加锁方式混合，它反而 
 会支持填加，删除和更新。  
  
 -------------------------------------------------------------------------- 
  
     SELECT 语句中“加锁选项”的功能说明  
  
 SQL Server提供了强大而完备的锁机制来帮助实现数据库系统的并发性和高性能。用户既能使用SQL Server的缺省设置也可以在select 语句中使用“加锁选项”来实现预期的效果。 本文介绍了SELECT语句中的各项“加锁选项”以及相应的功能说明。  
 功能说明：　   
 NOLOCK（不加锁）   
 此选项被选中时，SQL Server 在读取或修改数据时不加任何锁。 在这种情况下，用户有可能读取到未完成事务（Uncommited Transaction）或回滚(Roll Back)中的数据, 即所谓的“脏数据”。   
  
 HOLDLOCK（保持锁）   
 此选项被选中时，SQL Server 会将此共享锁保持至整个事务结束，而不会在途中释放。   
  
 UPDLOCK（修改锁）   
 此选项被选中时，SQL Server 在读取数据时使用修改锁来代替共享锁，并将此锁保持至整个