博文
解决密码中包含{}，密码修改成功后, 查询分析器无法用此密码登录的问题(2006-08-07 11:51:00)
摘要：
问题描述:
在修改SQL Server 2000的sa密码时在密码中包含了{}字符，例如所修改的密码为：“{password}”（双引号中的字符为密码的全部字符），密码修改成功了，可是用sa登录名及密码{password}再登录不上去，请问哪位高手也曾经碰到这样的情况，有没有解决的办法？
解决方法:
如果有其他管理员用户，或者是默认的登录BUILTIN/Administrators和<机器名>/Administrator之一没有被禁用，且还具有管理员权限，则可以用管理员用户，或者是Windos身份验证登录，并用下面的语句把密码改为普通的字符即可：
EXEC sp_password NULL, 'newpassword', 'sa'
特殊情况:
如果上述方法的环境并不存在，则可以用下面的这些方法来解决:
1. 如果你装有sql 2005的manger studio的话, 可以用2005的manger studio连接来改密码.；
2. 经测试，在系统ODBC数据源中，创建一个系统DSN，连接到sql server，使用这种特殊的密码也没有问题，因此，可以用程序连接sql server来改密码.；
3. 可以使用ISQL来修改密码，在命令提示符下输入：
isql /S"sql服务器名" /U"sa" /P"{password}" /Q"sp_password NULL, 'newpassword', 'sa'"......
与SQL Server补丁相关的问题(2006-08-07 11:51:00)
摘要：
1 分布式事务的问题
http://community.csdn.net/Expert/topic/4874/4874208.xml?temp=.298443
执行下面的语句:
INSERT INTO aa SELECT * FROM SrvA.DbA.dbo.tbA
BEGIN TRAN
INSERT INTO B SELECT * FROM AA
COMMIT TRAN
出现错误:
服务器: 消息7391，级别16，状态1，过程UP_transPROC，行24
该操作未能执行，因为OLE DB 提供程序'SQLOLEDB' 无法启动分布式事务。
[OLE/DB provider returned message: 新事务不能登记到指定的事务处理器中。
答：
SQL Server 2005和SQL Server 2000 sp3及以上均无此问题........
如何实现横向聚合(2006-08-07 11:50:00)
摘要：
问题描述：
有表tb，数据如下
A1 A2 A3 A4 A5
1 2 5 3 4
2 2 3 4 5
0 3 4 2 5
如何输出
A1 A2 A3 A4 A5 最大 最小 5以上个数
1 2 5 3 4 5 1 1
2 2 3 4 5 5 2 1
0 3 5 2 6 6 0 2
答：
SQL Server的聚合函数是在列上的，所以可以写自定义的函数，也可以想办法把列变为行，再用聚合函数处理
解决示例
--测试数据
DECLARE @t TABLE(A1 int, A2 int, A3 int, A4 int, A5 int)
INSERT @t SELECT 1,2,5,3,4
UNION ALL SELECT 2,2,3,4,5
UNION ALL SELECT 0,3,4,2,5
--查询
SELECT *,
[min] = (
SELECT MIN(v) FROM(
SELECT v=A.A1 UNION SELECT v=A.A2 UNION SELECT v=A.A3
&......
估计表大小（三）--估计无聚集索引的表的大小(2006-08-07 11:50:00)
摘要：
估计无聚集索引的表的大小
下列步骤可用于估计存储没有聚集索引的表上的数据和任何附加的非聚集索引所需的空间。
计算存储数据所用的空间。
计算存储每个附加非聚集索引所用的空间。
汇总计算所得的值。
对于每个计算，都要指定将在表中出现的行数。表中的行数将对表的大小有直接影响：
表中的行数 = Num_Rows
计算存储数据所用的空间
若要计算存储数据所用的空间，请参见估计表的大小。
记下计算所得的值：
存储数据所用的空间 = Data_Space_Used
计算存储每个附加非聚集索引所用的空间
下列步骤可用于估计没有聚集索引的表上的单个非聚集索引的大小。
如果索引定义包含固定长度和可变长度列，请计算索引行中这两组列的每一组所占用的空间。列的大小取决于数据类型和长度说明。有关更多信息，请参见数据类型。
索引键中的列数 = Num_Key_Cols
所有固定长度键列中的字节总和 = Fixed_Key_Size
索引键中的可变长度列数 = Num_Variable_Key_Cols
所有可变长度键列的最大值 = Max_Var_Key_Size
如果索引中有固定长度列，那么索引行的一部分将为空位图保留。计算大小：
索引空位图 (Index_Null_Bitmap) = 2 + (( Num_Key_Cols + 7) / 8 )
仅使用上述表达式中的整数部分，而去掉其余部分。
如果索引中有可变长度列，请确定存储索引行中的这些列需使用的空间：
可变长度列的总大小 (Variable_Key_Size) = 2 + (Num_Variable_Key_Cols x 2) + Max_Var_Key_Size
如果没有可变长度列，请将 Variable_Key_Size 设置为 0。
此公式假设所有可变长度键列均百分之百充满。如果预计可变长度键列占用的存储空间比例较低，则可以按照该比例调整结果以对整个索引大小得出一个更准确的估计。
计算索引行大小：
索引行总大小 (Index_Row_Size) = Fixed_Key_Size + Variable_Key_Size + Index_Null_Bitmap + 1 + 8
下一步，计算每页的索引行数（每页有 8096 个可用字节）......
估计表的大小（二）--估计带有聚集索引的表的大小(2006-08-07 11:49:00)
摘要：
估计带有聚集索引的表的大小
下列步骤可用于估计存储带有聚集索引的表上的数据和任何附加的非聚集索引所需的空间。
计算存储数据所用的空间。
计算存储聚集索引所用的空间。
计算存储每个附加非聚集索引所用的空间。
汇总计算所得的值。
对于每个计算，都要指定将在表中出现的行数。表中的行数将对表的大小有直接影响：
表中的行数 = Num_Rows
计算存储数据所用的空间
有关如何计算存储数据所用空间的更多信息，请参见估计表的大小。
记下计算所得的值：
存储数据所用的空间 = Data_Space_Used
计算存储聚集索引所用的空间
下列步骤可用于估计存储聚集索引所需的空间。
聚集索引定义可以包括固定长度和可变长度列。为了估计聚集索引的大小，需要指定索引行中这两组列的每一组所占用的空间。
索引键中的列数 = Num_CKey_Cols
所有固定长度键列中的字节总和 = Fixed_CKey_Size
索引键中的可变长度列数 = Num_Variable_CKey_Cols
所有可变长度键列的最大值 = Max_Var_CKey_Size
如果聚集索引中有固定长度列，那么索引行的一部分将为空位图保留。计算大小：
索引空位图 (CIndex_Null_Bitmap) = 2 + (( Num_CKey_Cols + 7) / 8 )
仅使用上述表达式中的整数部分，而去掉其余部分。
如果索引中有可变长度列，请确定存储索引行中的这些列需使用的空间：
可变长度列的总大小 (Variable_CKey_Size) = 2 + (Num_Variable_CKey_Cols x 2) + Max_Var_CKey_Size
如果没有可变长度列，请将 Variable_CKey_Size 设置为 0。
此公式假设所有可变长度键列均百分之百充满。如果预计可变长度键列占用的存储空间比例较低，则可以按照该比例调整结果以对整个索引大小得出一个更准确的估计。
计算索引行大小：
索引行总大小 (CIndex_Row_Size) = Fixed_CKey_Size + Variable_CKey_Size + CIndex_Null_Bitmap + 1 + 8
下一步，计算每页的索引行数（每页有 80......
估计表的大小（一）(2006-08-07 11:49:00)
摘要：
估计表的大小
下列步骤可用于估计存储表中的数据所需的空间量。
指定表中的行数：
表中的行数 = Num_Rows
如果在表的定义中有固定长度和可变长度列，请计算数据行中这两组列的每一组所占用的空间。列的大小取决于数据类型和长度说明。有关更多信息，请参见数据类型。
列数 = Num_Cols
所有固定长度列中的字节总和 = Fixed_Data_Size
可变长度列数 = Num_Variable_Cols
所有可变长度列的最大值 = Max_Var_Size
如果表中有固定长度列，行的一部分（称为空位图）将保留以管理列的可为空性。计算大小：
空位图 (Null_Bitmap) = 2 + (( Num_Cols + 7) / 8 )
仅使用上述表达式中的整数部分，而去掉其余部分。
如果表中有可变长度列，请确定在行中存储这些列需使用的空间：
可变长度列的总大小 (Variable_Data_Size) = 2 + (Num_Variable_Cols x 2) + Max_Var_Size
如果没有可变长度列，请将 Variable_Data_Size 设置为 0。
此公式假设所有可变长度列均百分之百充满。如果预计可变长度列占用的存储空间比例较低，则可以按照该比例调整结果以对整个表大小得出一个更准确的估计。
计算行大小：
行总大小 (Row_Size) = Fixed_Data_Size + Variable_Data_Size + Null_Bitmap +4
最后一个值 4 表示数据行首结构。
下一步，计算每页的行数（每页有 8096 可用字节）：
每页的行数 (Rows_Per_Page) = ( 8096 ) / (Row_Size + 2)
因为行不跨页，所以每页的行数应向下舌入到最接近的整数。
如果要在表上创建聚集索引，那么要根据指定的填充因子计算每页保留的可用行数。有关更多信息，请参见填充因子。如果不创建聚集索引，请将 Fill_Factor 指定为 100。
每页的可用行数 (Free_Rows_Per_Page) = 8096 x ((100 - Fill_Factor) / 100) / (Row_Size + 2)
计算中使用的填充因子为整数值，而不是......
企业管理器中设置权限时, 勾、叉和什么都不选，在权限控制上有什么区别？(2006-08-07 11:48:00)
摘要：
问题描述:
企业管理 -〉登陆 -〉名称 —〉属性—〉数据库访问 -〉public -〉属性 -〉权限
设置对某张访问控制表
其中 打勾号是什么意思？
打叉号又是什么意思？
什么都不打是什么意思？
答：
勾: 明确的授予
叉: 明确的拒绝
不打: 由他所属的角色等决定他的权限
示例说明：
用户A, 是角色A的成员. 角色A具有对表 tb 的 select 权限
如果对用户A授予(打勾)对表 tb 的 select 权限, 则用户A肯定有表 tb 的 select 权限
如果对用户A拒绝(打叉)对表 tb 的 select 权限, 则用户A肯定没有表 tb 的 select 权限(虽然角色A有权限, 但我们已经明确设置拒绝了, 所以用户A无法继承角色A的对表 tb 的select 权限)
而不选的话, 则虽然没有授权用户A对 tb 的 select 权限, 但角色A有, 所以用户A一样对tb有 select 权限.......
SQL各种写法的效率问题(2006-08-07 11:47:00)
摘要：
问：
(1)一次插入多条数据时:
CREATE TABLE tb(ID int, 名称 NVARCHAR(30), 备注 NVARCHAR(1000))
INSERT tb SELECT 1,'DDD',1
UNION ALL SELECT 1,'5100','D'
UNION ALL SELECT 1,'5200','E'
也可以这样:
CREATE TABLE tb1(ID int, 名称 NVARCHAR(30), 备注 NVARCHAR(1000))
INSERT TB1 (ID,名称,备注)VALUES(1,'DDD',1)
INSERT TB1 (ID,名称,备注)VALUES(1,'5100','D')
INSERT TB1 (ID,名称,备注)VALUES(1,'5200','E')
_________________________________
上面两种方法,哪种方法效率高?
答：
第1种好一些, 但也得有个量的控制, 因为第1种的union all是作为一个语句整体, 查询优化器会尝试做优化, 同时, 也要先算出这个结果再插入的.
问：
(2)赋值时:
SELECT @a=N'aa'
SET @a=N'aa'
_________________________________
上面两种方法,哪种方法效率高?
答：
如果是单个赋值, 没有什么好比较的话.
不过, 如果是为多个变量赋值, 经测试， SELECT 一次性赋值, 比用SET 逐个赋值效率好..
问：
(3)取前几条数据时
set ROWCOUNT 2 select * from tb order by fd
select Top 2 * from tb order by fd
_________________________________
上面两种方法,哪种方法效率高?
答：
SET ROWCOUNT和TOP 是一样......
TOP 1比不加TOP慢的疑惑(2006-08-07 11:46:00)
摘要：问题描述：
有一个查询如下，去掉TOP 1的时候，很快就出来结果了，但加上TOP 1的时候，一般要2~3秒才出数据，何解？
SELECT TOP 1
A.INVNO
FROM A, B
WHERE A.Item = B.ItemNumber
AND B.OwnerCompanyCode IS NOT NULL
问题原因分析：
在使用TOP 1的时候，SQL Server会尽力先找出这条TOP 1的记录，这就导致它采用了与不加TOP时不一致的扫描算法，SQL Server查询优化器始终认为，应该可以比较快的找到匹配的第1条记录，所以一般是使用嵌套循环的联接，则不加TOP 1时，SQL Server会根据结构和数据的统计信息决策出联接策略。嵌套循环一般适用于联系的两个表，一个表的数据较大，而另一个表的数据较小的情况，如果查询匹配的值出现在扫描的前端，则在取TOP 1的情况下，是符合嵌套循环联系的使用条件的，但当匹配的数据出现在扫描的后端，或者是基本上没有匹配的数据时，则嵌套循环要扫描完成两个大表，这显然是不适宜的，也正是因为这种情况，导致了TOP 1比不加TOP 1的效率慢很多
关于此问题的模拟环境：
USE tempdb
GO
SET NOCOUNT ON
--======================================
--创建测试环境
--======================================
RAISERROR('创建测试环境', 10, 1) WITH NOWAIT
-- Table A
CREATE TABLE [dbo].A(
[TranNumber] [int] IDENTITY(1, 1) NOT NULL,
[INVNO] [char](8) NOT NULL,
[ITEM] [char](15) NULL DEFAULT (''),
PRIMARY KEY([TranNumber])
)
&......
ASP.NET 中的正则表达式(2006-08-07 11:44:00)
摘要：引言
Microsoft®.NET Framework 对正则表达式的支持是一流的，甚至在 Microsoft® ASP.NET 中也有依赖正则表达式语言的控件。本文介绍了深入学习正则表达式的基础知识和推荐内容。
本文主要面向对正则表达式知之甚少或没有使用经验，但却熟悉 ASP.NET、可借助 .NET 编程的初学者。此外，希望本文连同 regular expression cheat sheet 成为有正则表达式使用经验的开发者的手头参考资料或进修资料。本文讨论内容如下：
1.
正则表达式使用历史简介
2.
简单表达式
3.
限定符
4.
元字符
5.
字符类
6.
预定义的集合元字符
7.
表达式示例详细内容
8.
ASP.NET 中的验证
9.
正则表达式 API
10.
免费工具
11.
高级主题概述
12.
小结和其他资源
通常，如果对本文或对正则表达式有疑问，请访问 http://www.aspadvice.com/，通过 regex mailing list 提出问题。编写此文时其中已有 350 多个订户参与。
返回页首
正则表达式使用历史简介
正则表达式设计于五十年代，存在至今。正则表达式最初用于描述“正则集”，它们是一些神经生理学家研究的模式。正则表达式最早由数学家 Stephen Kleene 提出，最终由 Ken Thompson 在两种非常流行的文本实用程序 qed 和 grep 中使用。Jeffrey Friedl 在其著作“Mastering Regular Expressions (2nd edition)”中对此作了进一步阐述。建议那些希望更多了解正则表达式理论和历史的人看看这本书。
在最近的五十年中，正则表达式逐渐从模糊深奥的数学概念发展为在各类工具和软件包中应用的主要功能。尽管数十年来很多 UNIX 工具都支持正则表达式，但仅仅是近十年来，它才在大部分 Windows 开发者工具包中得到体现。在 Microsoft® Visual Basic® 6 或 Micro......