锁初探(sqlserver 2005)
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 指定该锁，这种情况下排它锁适用于适当级别的粒度锁的概述
一. 为什么要引入锁
多个用户同时对数据库的并发操作时会带来以下数据不一致的问题: 丢失更新
A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果,比如订票系统
脏读
A用户修改了数据,随后B用户又读出该数据,但A用户因为某些原因取消了对数据的修改,数据恢复原值,此时B得到的数据就与数据库内的数据产生了不一致
不可重复读
A用户读取数据,随后B用户读出该数据并修�
相关文档：
本篇内容系属SQLServer高级编程，适用于欲提高自己和复习或应付面试的朋友阅读，同时本人学习不久，在总结和归纳时错误和不恰当之处在所难免，还请指出其中‘端倪’，予以完善。
表1:Users
USE [Wish]
GO
/****** 对象: Table [dbo].[Users] 脚本日期: ......
//这是添加
private void button1_Click(object sender, EventArgs e)
{
string s = "Persist Security Info=False;Integrated Security=SSPI;database=IIntegration;server=(local)";
&n ......
只让指定的机器连接SQLServer服务器 收藏
背景
只想使某个IP的计算机才能连接到SQL Server服务器，不允许其他客户端连接。
解决方法
可以直接在防火墙中做限制，只允许与指定的IP地址建立1433的通讯。当然，从更为安全的角度来考虑，应该把1433端口改成其他的端口。
其他解决方法1（限从指定IP接入的客户端）
如果使 ......
可以用扩展存储过程xp_dirtree获取文件列表，用openrowset倒入数据到二进制字段。
openrowset的用法可以参考msdn
http://technet.microsoft.com/zh-cn/library/ms190312.aspx
如果文件很多，建议还是用程序倒入了
if (object_id ('t_bulkResult' ) is not null )
drop table t_bulkResult ......
SQLServer中有两个扩展存储过程实现Scanf和Printf功能，恰当的使用它们可以在提取和拼接字符串时大幅度简化SQL代码。
1、xp_sscanf，用它可以分解格式相对固定的字符串，这对于厌倦使用一堆substring和charindex的朋友来说不错。比如前几天的一个帖子中提出的如何分解ip地址，相对简练且通用的代码应该是下面这样
------- ......
