在给客户解决一个小的技术问题时，发现一些技术人员对SQL2005的T-SQL还有些东西是不太熟悉的，这次我就通过与SQL2000对比着来说一下SQL2005的TOP子句吧。

首先说一下大家熟悉的SELECT语句。

SQL2000中我们主要类似这样写：SELECT TOP 10 * FROM [News] ORDER BY [Id] DESC。这样我就能获取News表按Id列倒序的前10条记录。那么一个小问题就来了，我们知道SQL2000的TOP后面只能跟常量的，不能跟变量的，如果我们把这个语句放在一个存储过程中，而由于业务原因一些地方需要取出同样条件的10条有些20条还有57条……，那么我们怎么办呢？很多人说“简单啊，存储过中声明一个 @Top AS INT 的参数，然后先写一行SET ROWCOUNT @Top;然后写一行SELECT * FROM [News] ORDER BY [Id] DESC; 就行了。对了，最好在后面紧接着加上SET ROWCOUNT 0; 以避免影响后面的查询语句”。嗯这个回答在SQL2000是比较对的，起码比回答重新组合SQL语句的要好一些，尤其最好不要忘记那个SET ROWCOUNT 0; 但是我们看到这种方式在实际应用中，体验是不好的，一旦语句复杂到一定程度时，SET ROWCOUNT前后影响可能会让SQL编写人员撞墙。ok,那么我们在SQL2005中该如何处理呢？
SQL2005中SELECT语句的TOP则方便多了，因为TOP支持使用任意的独立表达式，而不仅仅是常量。所以我们上面的同样问题可以简化为:SELECT TOP (@Top) * FROM [News] ORDER BY [Id] DESC。人性化多了，而且语句表达的意思很明确，不会像使用SET ROWCOUNT那样让人郁闷不已。

再说一下INSERT、UPDATE和DELETE等修改语句吧。

对于这三种操作我们似乎依然可以使用SET ROWCOUNT来处理，但是我们知道这种方式的体验之差，对复杂语句尤甚。而且我们知道“对于在远程表和本地及远程分区视图上执行的 INSERT、UPDATE 和 DELETE 语句，将忽略 SET ROWCOUNT 选项设置”，也就是说在远程查询时这个东西就不管用了。我们还在SQL2008的联机丛书中还发现这样一段重要提示：
“在 SQL Server 的下一个版本中，使用 SET ROWCOUNT 将不会影响 DELETE、INSERT 和 UPDATE 语句。请不要在新的开发工作中将 SET ROWCOUNT 与 DELETE、INSERT 和 UPDATE 语句一起使用，并应准备修改当前使用它的应用程序。另外，对于当前使用 SET ROWCOUNT 的 DELETE、INSERT 和 UPDATE 语句，建议您使用 TOP 语法重写它们。”
正如上述提示中诉说的，我们应该选择更灵活、更人性化，而且还能在未来升级到新版本SQL数据库时减少麻烦的TOP子句。三种例句如下：
INSERT TOP(100) INTO [News] SELECT [Id],[Title]，[Author] from [OldNews];
UPDATE TOP(500) [News] SET [Author] = N'qihangnet' WHERE Id >2009;
DELETE TOP(100) FROM [News];

值得注意的是上述这三种修改数据表的语句中，我们均无法直接使用ORDER BY附加排序条件，所以上述三种语句带有一定的随机性，尤其是UPDATE和DELETE语句。当然这种随机性有其两面性，优点是比如在按量分配工作的业务中，可以很方便的使用UPDATE进行随机性修改一定量的数据；缺点是当我们想通过排序控制一定量的数据时就不好了。那么真对于这种缺点我们是否就没有办法了呢？其实在SQL2005中，已经提供了可以轻松解决这个问题的方法，那就是利用WITH语句。具体方法在我们稍后的讨论WITH语句的博客文章中进行说明，并通过几个例子来详细说明一下WITH的妙用。

    近期在对一些客户做技术培训的时候，发现了一个问题。一些我们平常天天在用的软件工具，比如：Windows、Office、SQL Server、Visual Studio等等，很多都没有得到用户较充分的使用。很多已经被软件厂商早已攻克的问题，却在用户那里在被重复研究解决方案，原因为什么？因为用户根本不知道原来这个每天都在用的软件工具还有这样或那样的功能，可以解决我们目前所碰到的问题。比如说：

• Excel就已经可以轻松解决家庭的收支结算问题，有人却偏偏要安装什么管家婆或者形形色色的所谓家庭财务管理软件，甚至还要求你安装个sql server呢。难道你只把excel当作一个普通表格使用吗？
• 不少人抱怨Word排版很差，对文章分层次时，要手工敲入那些“第一、第二”或者“1)、2)”等，为什么不用编号功能呢？
• sql server 2005 有个“数据库引擎优化顾问”，可以在一定程度上帮助优化数据库，而对应于sql 2000中也存在“索引优化向导”，而他们都依赖于sql profile，另外数据库有执行计划等一系列分析优化的工具，为什么连这些都没用过就问人索要什么优化工具呢？
• Windows自身就带有磁盘清理等系统优化工具，为啥你只为了清理一下系统盘的空间，却要安装“超级**”或是“**优化大师”呢？

    上述都只是一些简单的例子，但在相当多用户中存在类似的问题，而在软件开发人员中问题依然不少见。问题出在哪里，用户自身是问题之一，而作为软件提供商来说，是否应该考虑一下自身的问题，是否应该下一下功夫对用户进行培训教育呢？UI是否可以设计的再合理一些，让用户更直接的了解到软件的已有功能呢？

     正如某些分析师说的：“微软的Windows、Word和Excel等产品中功能丰富,但消费者却并不完全了解.其结果就是,消费者耗费大量的时间来解决一些微软产品已经攻克的问题.因此,鲍尔默应该在该领域投入一笔资金,以帮助用户了解微软产品的功能”。个人认为这样这个问题不光是微软应该考虑的问题，IBM、Oracle以及我们国内的金山等软件企业是否也应该思考呢？共享软件作者亦应如此。

在一些网站或者软件系统中，由于安全或者程序异常等问题，可能会在SQL Server 2000中造成一个异常问题：在企业管理器中打开数据库发现有一些“坏表”，即无法使用，也无法正常删除。其原因往往是因为在尝试建表的过程中，只向数据库服务器的系统表sysobjects中写入了类型为“U”的记录，却并未真正在数据库中成功创建该表的实体。ok，解决问题有思路了:

假设“坏表”的表名为cmd，那么我们在查询分析器中对当前的数据库写一个sql语句：

delete from sysobjects where [name]='cmd' and xtype='U'

按F5执行，可能会碰到一个错误提示：“未启用对系统目录的特殊更新。系统管理员必须重新配置 SQL Server 以允许这种操作。” 解决这个小小的问题的方法是：打开mssql server 属性---》服务器选项----》启用对系统目录的特殊更新(允许对系统目录进行直接修改)  即可。之后重新在查询分析器中执行刚才的sql语句。

执行成功后。在企业管理器中会发现那个坏表已经不存在了。

[ 注：SQL2005中，由于微软做了重大调整，正常情况下不允许对系统表进行即席更新操作。所以本文提到的问题目前仅适用于SQL2000数据库，敬请注意 ]

asp.net 2.0中引入的Membership机制给我们做web开发带来很多便利，使得我们在做很多项目开发时处理用户和角色及权限问题时减少了相当的工作量。不过我们开发中可能会碰到一个小小的问题如下：

我们知道MembershipUser中有如下重载的方法

• MembershipUser.ResetPassword () ：将用户密码重置为一个自动生成的新密码。
• MembershipUser.ResetPassword (String passwordAnswer) ：将用户密码重置为一个自动生成的新密码。

msdn中有如下描述：

ResetPassword 调用 ProviderName 属性所引用的成员资格提供程序的 MembershipProvider.ResetPassword 方法，以将成员资格用户的密码重置为自动生成的新密码。然后将该新密码返回到调用方。

如果 EnablePasswordReset 为 false，则成员资格提供程序将返回一个异常。

如果 RequiresQuestionAndAnswer 为 true，则必须使用以密码提示问题答案作为参数的 ResetPassword 重载方法，并提供成员资格用户的密码。如果需要密码答案并提供了不正确的密码答案，成员资格提供程序将引发 MembershipPasswordException。

而另外一个方法MembershipUser.ChangePassword(String oldPassword, String newPassword) 又必须提供原始密码，那么这里就产生了一个矛盾：我们希望用户能够通过安全问题和答案来作为找回密码，又希望管理员可以重置某用户的密码怎么办？上述方法均无法直接使用，要么使用MembershipUser.ResetPassword ()而无安全问题和答案验证，要么必须知道问题答案或者原始密码，我们知道这些安全相关的东西我们都是加密的，而且往往采用单向编码的方式，也是说我们不可能轻易的通过读取数据库数据知道用户的答案和旧密码！那么好，如何解决这个问题呢？下面我来提供一个小的解决方案：

Membership的数据库中包含有一个设置用户密码的存储过程：

          CREATE
          PROCEDURE aspnet_Membership_SetPassword
( @ApplicationName nvarchar(256), @UserName nvarchar(256), @NewPassword nvarchar(128),
@PasswordSalt nvarchar(128), @CurrentTimeUtc datetime, @PasswordFormat int =
0 ) 

返回值：成功返回 0；
用户不存在，返回 1；

那么ok,我们开始解决我们的需求吧！思路很简单我们先设置用户一个默认的密码，然后以该密码为旧密码使用MembershipUser.ChangePassword(String oldPassword, String newPassword) 修改用户的密码。下面的代码是在以DataAccess.RunProcedure方法是已经实现的执行存储过程的方法为前提编写的：

            
              public
              class MembershipSafe
{ publicstaticstring ResetPassword(string username)
{ //将用户密码修改为8位且包含一个特殊符号的随机密码return ResetPassword(username,
Membership.GeneratePassword(8,1)); } publicstaticstring ResetPassword(string username, string newpassword)
{ //先将用户密码修改为123123 SqlParameter[]
_sp = { new SqlParameter("@ApplicationName",Membership.ApplicationName)
,new SqlParameter("@UserName",username)
,new SqlParameter("@NewPassword","1M4h3eZLAKW1WbVTTwYJiJZa33w=")
,new SqlParameter("@PasswordSalt","rcVy3pCccZ9tXW7NHp1Maw==")
,new SqlParameter("@CurrentTimeUtc",DateTime.Now)
,new SqlParameter("@PasswordFormat",1)
}; bool op = DataAccess.RunProcedure("aspnet_Membership_SetPassword",
_sp) == 0; //以123123为原始密码，修改为新密码 Membership.GetUser(username).ChangePassword("123123",
newpassword); return newpassword;
} } 
          

注：以上代码仅做参考，不一定是符合您具体项目的需求，比如有人可能会继续问修改了密码怎么告诉用户啊，答案是发邮件或者电话通知啊，哈哈～～

推荐浏览：

• Windman写的 ＂揪出ASP.NET 2.0四大“插件”的总后台 -- ASPNETDB ＂

数据库镜像是SQL Server 2005的一个新特性，它允许你将一个SQL Server中的数据库内容镜像到另一个SQL Server上。它还让你可以在发生错误的时候，通过镜像数据库来进行错误恢复。镜像的拷贝是一个备用的拷贝，不能直接访问,它只用在错误恢复的情况下。SQL2005的这一特性给数据库系统维护人员带来了不错的实惠，而给最终用户的体验也是不错的。至于如何配置数据库镜像系统，大家可以到TechNet 中文网络广播 中查找一下相关视频教程，尤其推荐大家去看看MVP牛可的相关讲座视频哦。再这里就不多说了。我们直奔主题吧！！

在使用数据库镜像功能时，如果我们使用的是工作组，那么我们需要注意一下数据库用户的问题：用普通方式创建的数据库用户，在主数据库中和镜像数据库中是有一些差异的，而这个差异最终会造成一个“奇怪”的结果，我们在主数据库和镜像数据库中对某数据库影射的“相同用户”，在发生故障转移后数据库验证会发生异常，称该用户无法登录我们的数据库，WHY? 原来是两个数据库中的同名用户在系统表syslogins中的sid不同造成的。解决方法就是在两个数据库上建立同名同sid的用户，具体方法如下：

假设有镜像的服务器是MIR-A和MI-B，要访问镜像数据库的登录账号是tom，使用下面这个方法就可以在MIR-A上创建登录名tom，然后在镜像数据库中创建数据库用户tom并映射到登录名tom
执行下列语句取回tom的sid

          
            select [name],
sid fromsysloginswhere [name]
= 'tom'
          

------  -----------------------------------------------

tom 0xD6AABCC8F83E3243A6C3C97F28A4CB55

然后在MIR-B上用下面的语句创建登录名tom

          sp_addlogin
@loginame = 'tom',
@passwd = 'password',
@sid = 0xD6AABCC8F83E3243A6C3C97F28A4CB55
        

Ok,这样就没有问题了。

好友前一阵子在他的博客上发表了一篇文章《安全设置 IIS 中的权限》，在这里转载一下，希望对大家有所帮助。

虽然 Apache 的名声可能比 IIS 好，但我相信用 IIS 来做 Web 服务器的人一定也不少。说实话，我觉得 IIS 还是不错的，尤其是 Windows 2003 的 IIS 6（马上 Longhorn Server 的 IIS 7 也就要来了，相信会更好），性能和稳定性都相当不错。但是我发现许多用 IIS 的人不太会设置 Web 服务器的权限，因此，出现漏洞被人黑掉也就不足为奇了。但我们不应该把这归咎于 IIS 的不安全。如果对站点的每个目录都配以正确的权限，出现漏洞被人黑掉的机会还是很小的（Web 应用程序本身有问题和通过其它方式入侵黑掉服务器的除外）。下面是我在配置过程中总结的一些经验，希望对大家有所帮助。

IIS Web 服务器的权限设置有两个地方，一个是 NTFS 文件系统本身的权限设置，另一个是 IIS 下网站->站点->属性->主目录（或站点下目录->属性->目录）面板上。这两个地方是密切相关的。下面我会以实例的方式来讲解如何设置权限。

IIS 下网站->站点->属性->主目录（或站点下目录->属性->目录）面板上有：

• 脚本资源访问
• 读取
• 写入
• 浏览
• 记录访问
• 索引资源

6 个选项。这 6 个选项中，“记录访问”和“索引资源”跟安全性关系不大，一般都设置。但是如果前面四个权限都没有设置的话，这两个权限也没有必要设置。在设置权限时，记住这个规则即可，后面的例子中不再特别说明这两个权限的设置。

另外在这 6 个选项下面的执行权限下拉列表中还有：

• 无
• 纯脚本
• 纯脚本和可执行程序

3 个选项。

而网站目录如果在 NTFS 分区（推荐用这种）的话，还需要对 NTFS 分区上的这个目录设置相应权限，许多地方都介绍设置 everyone 的权限，实际上这是不好的，其实只要设置好 Internet 来宾帐号（IUSR_xxxxxxx）或 IIS_WPG 组的帐号权限就可以了。如果是设置 ASP、PHP 程序的目录权限，那么设置 Internet 来宾帐号的权限，而对于 ASP.NET 程序，则需要设置 IIS_WPG 组的帐号权限。在后面提到 NTFS 权限设置时会明确指出，没有明确指出的都是指设置 IIS 属性面板上的权限。

例1 —— ASP、PHP、ASP.NET 程序所在目录的权限设置：

如果这些程序是要执行的，那么需要设置“读取”权限，并且设置执行权限为“纯脚本”。不要设置“写入”和“脚本资源访问”，更不要设置执行权限为“纯脚本和可执行程序”。NTFS 权限中不要给 IIS_WPG 用户组和 Internet 来宾帐号设置写和修改权限。如果有一些特殊的配置文件（而且配置文件本身也是 ASP、PHP 程序），则需要给这些特定的文件配置 NTFS 权限中的 Internet 来宾帐号（ASP.NET 程序是 IIS_WPG 组）的写权限，而不要配置 IIS 属性面板中的“写入”权限。

IIS 面板中的“写入”权限实际上是对 HTTP PUT 指令的处理，对于普通网站，一般情况下这个权限是不打开的。

IIS 面板中的“脚本资源访问”不是指可以执行脚本的权限，而是指可以访问源代码的权限，如果同时又打开“写入”权限的话，那么就非常危险了。

执行权限中“纯脚本和可执行程序”权限可以执行任意程序，包括 exe 可执行程序，如果目录同时有“写入”权限的话，那么就很容易被人上传并执行木马程序了。

对于 ASP.NET 程序的目录，许多人喜欢在文件系统中设置成 Web 共享，实际上这是没有必要的。只需要在 IIS 中保证该目录为一个应用程序即可。如果所在目录在 IIS 中不是一个应用程序目录，只需要在其属性->目录面板中应用程序设置部分点创建就可以了。Web 共享会给其更多权限，可能会造成不安全因素。

例2 —— 上传目录的权限设置：

用户的网站上可能会设置一个或几个目录允许上传文件，上传的方式一般是通过 ASP、PHP、ASP.NET 等程序来完成。这时需要注意，一定要将上传目录的执行权限设为“无”，这样即使上传了 ASP、PHP 等脚本程序或者 exe 程序，也不会在用户浏览器里就触发执行。

同样，如果不需要用户用 PUT 指令上传，那么不要打开该上传目录的“写入”权限。而应该设置 NTFS 权限中的 Internet 来宾帐号（ASP.NET 程序的上传目录是 IIS_WPG 组）的写权限。

如果下载时，是通过程序读取文件内容然后再转发给用户的话，那么连“读取”权限也不要设置。这样可以保证用户上传的文件只能被程序中已授权的用户所下载。而不是知道文件存放目录的用户所下载。“浏览”权限也不要打开，除非你就是希望用户可以浏览你的上传目录，并可以选择自己想要下载的东西。

例3 —— Access 数据库所在目录的权限设置：

许多 IIS 用户常常采用将 Access 数据库改名（改为 asp 或者 aspx 后缀等）或者放在发布目录之外的方法来避免浏览者下载它们的 Access 数据库。而实际上，这是不必要的。其实只需要将 Access 所在目录（或者该文件）的“读取”、“写入”权限都去掉就可以防止被人下载或篡改了。你不必担心这样你的程序会无法读取和写入你的 Access 数据库。你的程序需要的是 NTFS 上 Internet 来宾帐号或 IIS_WPG 组帐号的权限，你只要将这些用户的权限设置为可读可写就完全可以保证你的程序能够正确运行了。

例4 —— 其它目录的权限设置：

你的网站下可能还有纯图片目录、纯 html 模版目录、纯客户端 js 文件目录或者样式表目录等，这些目录只需要设置“读取”权限即可，执行权限设成“无”即可。其它权限一概不需要设置。

好了，我想上面的几个例子已经包含了大部分情况下的权限设置，其它情况根据这些例子，我想你一定可以想到该如何设置了吧。

一朋友问及一个问题：在SQL Server2000里如何通过sql语句查出指定数据表中自动编号的字段名，即包含标识的字段名。
其实使用一个简单的sql语句就搞定了：

          
            Select [name] FromsysColumnsWhere id=object_id(N'TABLENAME') and Status=128
        

其中TABLENAME为你要查询的数据表名称。

如果想查询标识种子和标识增量的信息，应使用如下语句：

            
              Select [name],autoval FromsysColumnsWhere id=object_id(N'TABLENAME') and Status=128
          

autoval字段的值包含了标识种子和标识增量信息，具体内容相信大家一看即明白了。在此不多说了^_^

另外，有人说查询主键时用Status=128是错误的，Status=128是用来查询标识字段的。

SqlServer的默认开放端口是1433，但是由于实际开发的需要端口被设置为非1433，一些开发人员不知如何写该类型的连接字符串了。
其实解决这个问题很简单的，只需在连接字符串的Data Source=myServer后面加上逗号和端口号就可以了。例如“……User ID=sa;Initial Catalog=pubs;Data Source=myServer,1200”，就是连接的1200端口的Sql Server服务器了。

具体的描述如下：
症状：
当您使用传输控制协议/Internet 协议 (TCP/IP) 以外的协议时，如果您指定 1433 以外的一个端口用以连接到 Microsoft SQL Server 的一个实例，则 SqlConnection.Open 会失败。
解决方案：
若要解决此问题，请使用 TCP/IP 协议，并使连接字符串中包括"Server=ComputerName, PortNumber"。

CREATE procedure main_table_pwqzc
(@pagesize int,
@pageindex int,
@docount bit,
@this_id)
as
if(@docount=1)
begin
selectcount(id) from luntan where this_id=@this_id
end
else
begin
declare @indextable table(id intidentity(1,1),nid int)
declare @PageLowerBound int
declare @PageUpperBound int
set @PageLowerBound=(@pageindex-1)*@pagesize
set @PageUpperBound=@PageLowerBound+@pagesize
set rowcount @PageUpperBound
insertinto @indextable(nid) select id from luntan where this_id=@this_id orderby reply_time desc
select a.* from luntan a,@indextable t where a.id=t.nid
and t.id>@PageLowerBound and t.id<=@PageUpperBound orderby t.id
end
GO

存储过程会根据传入的参数@docount来确定是不是要返回所有要分页的记录总数
特别是这两行

set rowcount @PageUpperBound
insertinto @indextable(nid) select id from luntan where this_id=@this_id orderby reply_time desc

真的是妙不可言!!set rowcount @PageUpperBound当记录数达到@PageUpperBound时就会停止处理查询
,select id 只把id列取出放到临时表里,select a.* from luntan a,@indextable t where a.id=t.nid
and t.id>@PageLowerBound and t.id<=@PageUpperBound orderby t.id 而这句也只从表中取出所需要的记录,而不是所有的记录,结合起来,极大的提高了效率!!
妙啊,真的妙!!!!

CREATE PROCEDURE Paging_RowCount
(
@Tables varchar(1000),
@PK varchar(100),
@Sort varchar(200) = NULL,
@PageNumber int = 1,
@PageSize int = 10,
@Fields varchar(1000) = '*',
@Filter varchar(1000) = NULL,
@Groupvarchar(1000) = NULL)
AS

/*Default Sorting*/
IF @Sort ISNULLOR @Sort = ''
SET @Sort = @PK

/*Find the @PK type*/
DECLARE @SortTable varchar(100)
DECLARE @SortName varchar(100)
DECLARE @strSortColumn varchar(200)
DECLARE @operator char(2)
DECLARE @type varchar(100)
DECLARE @prec int

/*Set sorting variables.*/
IFCHARINDEX('DESC',@Sort)>0
BEGIN
SET @strSortColumn = REPLACE(@Sort, 'DESC', '')
SET @operator = '<='
END
ELSE
BEGIN
IFCHARINDEX('ASC', @Sort) = 0
SET @strSortColumn = REPLACE(@Sort, 'ASC', '')
SET @operator = '>='
END


IFCHARINDEX('.', @strSortColumn) > 0
BEGIN
SET @SortTable = SUBSTRING(@strSortColumn, 0, CHARINDEX('.',@strSortColumn))
SET @SortName = SUBSTRING(@strSortColumn, CHARINDEX('.',@strSortColumn) + 1, LEN(@strSortColumn))
END
ELSE
BEGIN
SET @SortTable = @Tables
SET @SortName = @strSortColumn
END

SELECT @type=t.name, @prec=c.prec
FROMsysobjects o
JOINsyscolumns c on o.id=c.id
JOINsystypes t on c.xusertype=t.xusertype
WHERE o.name = @SortTable AND c.name = @SortName

IFCHARINDEX('char', @type) > 0
SET @type = @type + '(' + CAST(@prec ASvarchar) + ')'

DECLARE @strPageSize varchar(50)
DECLARE @strStartRow varchar(50)
DECLARE @strFilter varchar(1000)
DECLARE @strSimpleFilter varchar(1000)
DECLARE @strGroup varchar(1000)

/*Default Page Number*/
IF @PageNumber < 1
SET @PageNumber = 1

/*Set paging variables.*/
SET @strPageSize = CAST(@PageSize ASvarchar(50))
SET @strStartRow = CAST(((@PageNumber - 1)*@PageSize + 1) ASvarchar(50))

/*Set filter & group variables.*/
IF @Filter ISNOTNULLAND @Filter != ''
BEGIN
SET @strFilter = ' WHERE ' + @Filter + ' '
SET @strSimpleFilter = ' AND ' + @Filter + ' '
END
ELSE
BEGIN
SET @strSimpleFilter = ''
SET @strFilter = ''
END
IF @GroupISNOTNULLAND @Group != ''
SET @strGroup = ' GROUP BY ' + @Group + ' '
ELSE
SET @strGroup = ''

/*Execute dynamic query*/
EXEC(
'
DECLARE @SortColumn ' + @type + '
SET ROWCOUNT ' + @strStartRow + '
SELECT @SortColumn=' + @strSortColumn + ' FROM ' + @Tables + @strFilter + ' ' + @strGroup + ' ORDER BY ' + @Sort + '
SET ROWCOUNT ' + @strPageSize + '
SELECT ' + @Fields + ' FROM ' + @Tables + ' WHERE ' + @strSortColumn + @operator + ' @SortColumn ' + @strSimpleFilter + ' ' + @strGroup + ' ORDER BY ' + @Sort + '
'
)
GO

 在数据库应用的设计中，我们往往会需要获取某些表的记录总数，用于判断表的记录总数是否过大，是否需要备份数据等。我们通常的做法是：select count(*) as c from tableA 。然而对于记录数巨大的表，上述做法将会非常耗时。在DELL 4400 服务器上做试验，MS Sqlserver 2000 数据库对于100万记录的简单数据表执行上述语句，时间在1分钟以上。如果在表的某个字段上做聚簇索引，第一次执行该语句的时间和没有索引的时间差不多，之后执行上述语句，速度很快，在1秒中以内，但当表的记录数发生较大变化后，再执行该语句又会经历一次耗时的过程。而且不是每个表都适合做聚簇索引的，对于数量巨大的表，如果需要经常增删操作，建聚簇索引是一个很不明智的做法，将会极大的影响增删的速度。那么有没有一个比较简单的方法快速获取表的记录总数呢？答案是有的。
 在MS SQL 数据库中每个表都在sysindexes 系统表中拥有至少一条记录，该记录中的rows 字段会定时记录表的记录总数。下面是sysindexes 表的相关记录的含义：

列名      数据类型             描述
id            int                        表ID(如果 indid = 0 或255)。否则为索引所属表的ID
Indid       smallint                索引ID：
                                         0＝表
                                         1＝聚簇索引
                                         >1＝非聚簇索引
                                        255＝具有text或image数据的表条目。
rows       int                       基于indid=0 和 indid=1地数据级行数，该值对于indid>1重 复。如果indid=255，rows设置为0。
  
  
当表没有聚簇索引时，Indid = 0 否则为 1。

那么现在大家应该知道如何获取表的记录总数了，只需执行如下语句：
select rows from sysindexes where id = object_id(tablename) and indid in (0,1)

该方法获取表的记录总数的速度非常快，在毫秒级就可以完成，相比select count(*) 要快上数万倍，但是大家在运用该方法是一定要主要，该方法得到的表的总记录数不是一个精确值，原因是MS SQL 并不是实时更新该字段的值，而是定时更新，当从实践来看该值和精确值一般误差不大，如果你希望快速的粗略估算表的大小，建议你采用该方法。如果你希望得到精确值，那么请在执行上述语句前执行DBCC UPDATEUSAGE(DatabaseName,[TABLENAME]) WITH ROW_COUNTS 强制更新该字段的值，但这样第一次更新时会耗费大量的时间，这样做的效果和建有聚簇索引的表 select count (*) 效果相差不大，所以如果你希望相对快速地得到精确的表的记录总数，那么你有两种选择，建聚簇索引或者先DBCC 再使用上述方法。

现在我想得到一个在某个城市的员工名字的列表。(就使用SQL-Server预装的Northwind数据库)
下面给出最简单的实现：
 
         SqlDataAdapter da = new SqlDataAdapter(
      "SELECT * FROM Employees WHERE City='"+city+"'", nwindConn );
DataSet ds = new DataSet();
      da.Fill(ds,"Employees");
      foreach (DataRow dr in ds.Tables["Employees"].Rows)
      {
            string name = dr["LastName"].ToString();
int id = (int)dr["EmployeeID"];
            Console.WriteLine( id + ": " + name);
      }

让我们来看看有哪些地方容易出错：
1. city参数可能会被SQL注入攻击利用.
2. 数据类型是弱类型，需要强制转换类型，容易出现Runtime error.
3. 表名和列名都是文字，不是类型变量。编译器无法做检查，容易出现Runtime error.
   (想必不少人碰到过写错表名，导致数据库访问出错，而debug n久的事情.)
4. 查询语句也是文字，同样无法通过编译检查是否出错，容易出现Runtime error.

通过使用SqlParameters以及Typed DataSet我们可以避免前三个问题
          SqlDataAdapter da = new SqlDataAdapter(
            "SELECT * FROM Employees WHERE City= @city", nwindConn );
      SqlParameter cityParam = da.SelectCommand.Parameters.Add("@city", SqlDbType.VarChar, 80);
      cityParam.Value = city;
      NorthwindDataSet ds = new NorthwindDataSet();
      da.Fill(ds, ds.Employees.TableName );
      foreach (NorthwindDataSet.EmployeesRow dr in ds.Employees.Rows)
      {
            string name = dr.LastName;
            int id = dr.EmployeeID;
            Console.WriteLine( id + ": " + name);
      }

但是第四个问题仍没有解决。也许你想到了 SQL stored procedure，就像下面这样：    

      CREATE PROCEDURE EmployeesForCity
      @City nvarchar(80)  AS
      SELECT EmployeeID, LastName FROM Employees WHERE City = @City

       SqlCommand cmd = new SqlCommand( "dbo.EmployeesForCity", nwindConn );
      cmd.CommandType = CommandType.StoredProcedure;
      SqlParameter cityParam = cmd.Parameters.Add("@city", SqlDbType.VarChar, 80);
      cityParam.Value = city;
      SqlDataAdapter da = new SqlDataAdapter( cmd );
      NorthwindDataSet ds = new NorthwindDataSet();
      da.Fill(ds, ds.EmployeesForCity.TableName );
      foreach (NorthwindDataSet.EmployeesForCityRow dr in ds.EmployeesForCity.Rows)
      {
            string name = dr.LastName;
            int id = dr.EmployeeID;
            Console.WriteLine( id + ": " + name);
      }

SQL查询语句虽然不能在编译器检查，但是至少我们可以先在SQL-server中验证stored procedure，
再运行我们的程序,比Runtime error好多了。但是万一stored procedure改了，或者是数据库改了，
那我们又会看到Runtime error。问题的根本在于我们的代码和数据库的联系实在是太弱了。对于一
个小程序就如此容易出现问题，那么对于那种和数据库紧密联系的大型应用就更别谈了。

再来看看C-omega的解决方案：
        rows = select * from DB.Employees where City == city;            
      foreach( row in rows )
      {
            string name = row.LastName.Value;
            int id = row.EmployeeID.Value;
            Console.WriteLine( id.ToString() + ": " + name);
      }

以上代码需要引起注意的地方:
1. 可以将本地变量city直接放入SQL语句，不会被SQL注入攻击。
2. 结果集是强类型的，意味着在程序编译的时候我们就知道数据库的结构，甚至可以使用VS.net
所带的智能感知(自动完成)功能。
3. 在rows以及row前面甚至没有使用类型名，而它们却都是强类型的。
4. 不再含有文字类型的信息，避免了人为输入错误。
5. 在程序编译的时候就已经和数据库连接，当数据库发生变化的时候，在编译器就会报错。

如果你不喜欢SQL的语法，你甚至用三行代码就能搞定以上所有任务。
   DB.Employees [City==city].{ 
     Console.WriteLine( it.EmployeeID + ": " + t.LastName );
      };

从c++到C#我们常听见的一句话就是c＃是类型安全的。何谓类型安全？就是.Net Runtime支持编译期的类型检查。也就是尽量让Runtime error变成Compile error，可以看出Cω在这个方面更进了一步。

注：鉴于个人水平以及资料方面的原因对其内部机制实现笔者并为做深入研究。