Windows2000下DNS缓冲清除-
[
2005/06/29 23:08 | by ipaddr ]
2005/06/29 23:08 | by ipaddr ]
Ipaddr原创．
Windows2000的DNS解析，会有一个缓冲．
如果重新解析了一个域名，一般情况下，需要重启后才可以在本机起作用．
可以清除DNS缓冲，就可以让域名解析和服务器同步．
方法如下：
重新启动Windows2000的DNS Client服务．
可以在2003,XP上使用．
或者，直接使用命令：
ipconfig /flushdns
Windows2000的DNS解析，会有一个缓冲．
如果重新解析了一个域名，一般情况下，需要重启后才可以在本机起作用．
可以清除DNS缓冲，就可以让域名解析和服务器同步．
方法如下：
重新启动Windows2000的DNS Client服务．
可以在2003,XP上使用．
或者，直接使用命令：
ipconfig /flushdns
SugarCRM的JPGraph中文乱码解
[ 2005/06/25 22:25 | by ipaddr ]
2005/06/25 22:25 | by ipaddr ]
SugarCRM是一个开源的CRM软件．
基于PHP+Mysql的B/S系统．
2.0版的使用JPGraph生成统计图形，但中文会乱码．
原创:一直漂(e.it(at)163.com) 转载请说明
处理办法：
1.修改：
modules/Opportunities/Chars.php
第36行，直接加入一行：
return FF_SIMSUN;
2.修改：
jpgraph/src/jpg-config.inc
定义如下TTF目录(Linux是这个目录，Windows是winnt/fonts)
DEFINE("TTF_DIR","/usr/X11R6/lib/X11/fonts/TTF/");
修改以下定义:
DEFINE('USE_TRUECOLOR',false);
(修改后字体颜色正常.)
3.上传
simhei.ttf
simsun.ttc
这两个字体文件，到服务器的/usr/X11R6/lib/X11/fonts/TTF/
基于PHP+Mysql的B/S系统．
2.0版的使用JPGraph生成统计图形，但中文会乱码．
原创:一直漂(e.it(at)163.com) 转载请说明
处理办法：
1.修改：
modules/Opportunities/Chars.php
第36行，直接加入一行：
return FF_SIMSUN;
2.修改：
jpgraph/src/jpg-config.inc
定义如下TTF目录(Linux是这个目录，Windows是winnt/fonts)
DEFINE("TTF_DIR","/usr/X11R6/lib/X11/fonts/TTF/");
修改以下定义:
DEFINE('USE_TRUECOLOR',false);
(修改后字体颜色正常.)
3.上传
simhei.ttf
simsun.ttc
这两个字体文件，到服务器的/usr/X11R6/lib/X11/fonts/TTF/
关于SYN_RECV
[ 2005/06/13 23:09 | by ipaddr ]
2005/06/13 23:09 | by ipaddr ]
1.对于大量的 SYN_RECV
若怀疑是SYN Flood攻击，有以下建议:
这个攻击的解决方法如下：
1，增加未完成连接队列（q0)的最大长度。
echo 1280>/proc/sys/net/ipv4/tcp_max_syn_backlog
2, 启动SYN_cookie。
echo 1>/proc/sys/net/ipv4/tcp_syncookies
这些是被动的方法，治标不治本。而且加大了服务器的负担，但是可以避免被拒绝攻击（只是减缓）
治本的方法是在防火墙上做手脚。但是现在能在一定程度上防住syn flood攻击的防火墙都不便宜。并且把这个命令加入"/etc/rc.d/rc.local"文件中
如果对 /proc/sys/net/ipv4 下的配置文件进行解释，可以参阅 LinuxAid技术站的文章。查看本文全文也可以参阅。
关于 syn cookies， 请参阅 <> http://cr.yp.to/syncookies.html
也许 使用mod_limitipconn.c来限制apache的并发数 也会有一定的帮助。
2. iptables的设置，引用自CU
防止同步包洪水（Sync Flood）
# iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
也有人写作
#iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT
--limit 1/s 限制syn并发数每秒1次，可以根据自己的需要修改
防止各种端口扫描
# iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
Ping洪水攻击（Ping of Death）
# iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
附：
Iptables 指南 1.1.19
防火墙例子：
在Linux上使用iptables命令，建立一个个人防火墙
若怀疑是SYN Flood攻击，有以下建议:
这个攻击的解决方法如下：
1，增加未完成连接队列（q0)的最大长度。
echo 1280>/proc/sys/net/ipv4/tcp_max_syn_backlog
2, 启动SYN_cookie。
echo 1>/proc/sys/net/ipv4/tcp_syncookies
这些是被动的方法，治标不治本。而且加大了服务器的负担，但是可以避免被拒绝攻击（只是减缓）
治本的方法是在防火墙上做手脚。但是现在能在一定程度上防住syn flood攻击的防火墙都不便宜。并且把这个命令加入"/etc/rc.d/rc.local"文件中
如果对 /proc/sys/net/ipv4 下的配置文件进行解释，可以参阅 LinuxAid技术站的文章。查看本文全文也可以参阅。
关于 syn cookies， 请参阅 <> http://cr.yp.to/syncookies.html
也许 使用mod_limitipconn.c来限制apache的并发数 也会有一定的帮助。
2. iptables的设置，引用自CU
防止同步包洪水（Sync Flood）
# iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
也有人写作
#iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT
--limit 1/s 限制syn并发数每秒1次，可以根据自己的需要修改
防止各种端口扫描
# iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
Ping洪水攻击（Ping of Death）
# iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
附：
Iptables 指南 1.1.19
防火墙例子：
在Linux上使用iptables命令，建立一个个人防火墙
proc文件系统面面谈
[ 2005/06/13 23:08 | by ipaddr ]
2005/06/13 23:08 | by ipaddr ]
什么是proc文件系统
proc文件系统是一个伪文件系统，它只存在内存当中，而不占用外存空间。它以文件系统的方式为访问系统内核数据的操作提供接口。用户和应用程序可以通过proc得到系统的信息，并可以改变内核的某些参数。由于系统的信息，如进程，是动态改变的，所以用户或应用程序读取proc文件时，proc文件系统是动态从系统内核读出所需信息并提交的。它的目录结构如下：
proc文件系统是一个伪文件系统，它只存在内存当中，而不占用外存空间。它以文件系统的方式为访问系统内核数据的操作提供接口。用户和应用程序可以通过proc得到系统的信息，并可以改变内核的某些参数。由于系统的信息，如进程，是动态改变的，所以用户或应用程序读取proc文件时，proc文件系统是动态从系统内核读出所需信息并提交的。它的目录结构如下：
Dotnet环境下的crystal report的部署(上)
[ 2005/06/10 22:26 | by ipaddr ]
2005/06/10 22:26 | by ipaddr ]
项目的需要，要使用crystal做报表显示，水晶报表功能就是强大，做的报表就是漂亮，不过在使用过程中经常会遇到一些问题，很是麻烦，最可气的是其随软件的帮助有时都会误导你。下面我将我这次的经历展示一下，以免同道再走我的弯路。
我的开发环境是win xp professional + visual studio for .net 2002 + crystal for .net。
先是设计程序，设计报表rpt，关于怎么设计报表，这是个很复杂的事情，不过在这不是问题，也不是我要叙述的重点，反正我在上述环境下设计出来了一个可以显示报表的dotnet window应用程序，在这个开发环境下运行正常。
我尝试着把这个程序制作成一个MSI安装文件，然后去部署到没有visual studio for .net 2002 + crystal for .net的机器上。过程是这样的：
1. 在vs.net中的当前当前解决方案中新建一个安装项目。
2. 添加一个项目输出，把上述那个程序项目的主输出加入。
3. 系统会把这个引入的项目的相关依赖项都包含到“检测到的依赖项”文件夹中，这些依赖项都会被打包到MSI中。
4. build
以为系统会自动侦测出涉及到crystal for .net要使用到的组件，打包完后去目标机器安装（目标机器一共三台，分别是win98第二版，win2000 server，win xp professional），结果三台机器安装完后运行结果一样，当显示报表时，出现一下错误：
Cannot find KeycodeV2.dll, or invalid keycode
查找vs.net带的MSDN，发现部署Crystal Reports 运行时的说明：
分发应用程序时，须确定您的安装中所需要的 Crystal Decisions 文件。您要包括的文件取决于是否在报表中使用图表、地图和其他公式语言函数，同时也取决于报表所用的数据源以及您希望向最终用户提供的导出选项。幸运的是，如果您在使用 Microsoft Installer (MSI)，则可以在您的安装包中包括的合并模块 (MSM) 以简化分发。
MSI 合并模块可在“C:\Program Files\Common Files\Merge Modules”目录中找到。根据您正在分发的组件和语言，您可选用不同的合并模块。这些合并模块分为三类：托管组件、数据库访问和密钥号码。
托管组件 MSM 处理所有托管组件的分发，其中包括 Windows 窗体查看器、Web 窗体查看器和所有 Crystal Decisions 命名空间。对于使报表运行所需的所有其他文件，由数据库访问 MSM 处理其分发。其中包括数据库、导出和图表驱动程序。KeyCode MSM 处理 Crystal Decisions 密钥号码的安装，这样您的用户在查看报表时，就不会被要求注册他们的 Crystal 版本。
具体操作步骤：
1. 打开 Windows 应用程序。
在解决方案资源管理器中，右击 Windows 应用程序解决方案，指向“添加”，然后单击“新建项目”。
在“添加新项目”对话框中，选择“项目类型”窗格中的“安装和部署项目”，然后选择“模板”窗格中的“安装项目”。单击“确定”按钮。
在解决方案资源管理中，右击安装项目，指向“添加”，然后单击“项目输出”。
在“添加项目输出组”中，选择“主输出”，然后单击“确定”。
将自动添加所有依赖项，如 Managed.msm。
在解决方案资源管理器中，右击安装项目，指向“添加”，然后单击“合并模块”。
在“添加模块”对话框中，选择下列要添加到安装项目的合并模块，然后单击“打开”：
Database_Access.msm
Database_Access_enu.msm
regwiz.msm
VC_CRT.msm、VC_STL.msm（ 如果您部署的 Windows 应用程序使用 ADO.NET 数据集，则还需要包括 VC_CRT 和 VC_STL 合并模块）
在解决方案资源管理器中，右击 regwiz.msm 文件，然后选择“属性”。
在“属性”窗口中，展开 MergeModuleProperties，然后在“许可证密钥”属性框中输入一个有效的许可证密钥（密钥AAP5GKS0000GDE100DS）。
注意 每当部署 Crystal Reports 应用程序时，必须提供许可证密钥。
从“生成”菜单中，选择“生成解决方案”以生成应用程序。
按照上述步骤制作MSI安装文件，再次部署到目标机器（当部署到客户机或服务器时，应始终确保该计算机安装了 .NET Framework）。同样是安装到上述win98第二版，win2000 server，win xp professional这三台机器，结果是：
1. win98第二版，win xp professional这两台机器上运行正常，报表显示正常，报表导出也正常。
2. win2000 server机器上安装正常，显示报表正常，可是一旦点击了报表显示器中的导出图标，整个程序就死掉了，在任务管理器显示“未响应”，只能强行关掉。
这个结果勉强还可以接受，大不了这个程序不在win2000运行就是了。不过又发现一个新的问题，就是导出的word文档跟在报表显示器中显示的不是严格一致的，有一些差别，而且这个差别到了不可忍受的地步：
1. 在报表显示器中表格中的文字显示正常，在word中这些表格中的文字被转换成图文框中的，可是转换的图文框高度小了，导致了显示的文字的下面有一小部分显示不出来，效果就是一行文字都被吃掉了下面一部分。
2. 一张报表在报表显示器中显示的正好是一页纸，边距都很准确，可是导出的word文档，报表的内容的尾部跑到了页面以外。在设计crystal报表时页面设置是A4的，估计是导出到word文档时纸张的尺寸变了，不是A4了，而且导出的word文档的“页面设置”是暗的，不允许修改。
而这个软件中的报表一定是要导出到word的，这样的导出效果是不能接受的，于是想到是不是可是升级到crystal9 试试看。
crystal9是完全支持dotnet的，Crystal Reports 9 将其功能整合到了 Visual Studio .NET 集成开发环境 (IDE) 中，代替原先Crystal Reports for .net，从而增强了 Visual Studio .NET (VS .NET) 的开发效能。
安装了Crystal Report 9 Advanced Edtion 中文版，看vs.net的帮助中关于，看到crystal的信息显示为：Crystal Reports 9 for Visual Studio .NET，升级成功。
重新编译程序，在开发机器上运行程序，报表显示正常，主要是要看导出word文档显示是否正常，在报表显示器中点击导出按钮，导出word文档，结果是word文档显示同报表显示器中显示的报表一模一样，心中暗喜，问题解决了。
OK，现在要到部署的问题了。
我的开发环境是win xp professional + visual studio for .net 2002 + crystal for .net。
先是设计程序，设计报表rpt，关于怎么设计报表，这是个很复杂的事情，不过在这不是问题，也不是我要叙述的重点，反正我在上述环境下设计出来了一个可以显示报表的dotnet window应用程序，在这个开发环境下运行正常。
我尝试着把这个程序制作成一个MSI安装文件，然后去部署到没有visual studio for .net 2002 + crystal for .net的机器上。过程是这样的：
1. 在vs.net中的当前当前解决方案中新建一个安装项目。
2. 添加一个项目输出，把上述那个程序项目的主输出加入。
3. 系统会把这个引入的项目的相关依赖项都包含到“检测到的依赖项”文件夹中，这些依赖项都会被打包到MSI中。
4. build
以为系统会自动侦测出涉及到crystal for .net要使用到的组件，打包完后去目标机器安装（目标机器一共三台，分别是win98第二版，win2000 server，win xp professional），结果三台机器安装完后运行结果一样，当显示报表时，出现一下错误：
Cannot find KeycodeV2.dll, or invalid keycode
查找vs.net带的MSDN，发现部署Crystal Reports 运行时的说明：
分发应用程序时，须确定您的安装中所需要的 Crystal Decisions 文件。您要包括的文件取决于是否在报表中使用图表、地图和其他公式语言函数，同时也取决于报表所用的数据源以及您希望向最终用户提供的导出选项。幸运的是，如果您在使用 Microsoft Installer (MSI)，则可以在您的安装包中包括的合并模块 (MSM) 以简化分发。
MSI 合并模块可在“C:\Program Files\Common Files\Merge Modules”目录中找到。根据您正在分发的组件和语言，您可选用不同的合并模块。这些合并模块分为三类：托管组件、数据库访问和密钥号码。
托管组件 MSM 处理所有托管组件的分发，其中包括 Windows 窗体查看器、Web 窗体查看器和所有 Crystal Decisions 命名空间。对于使报表运行所需的所有其他文件，由数据库访问 MSM 处理其分发。其中包括数据库、导出和图表驱动程序。KeyCode MSM 处理 Crystal Decisions 密钥号码的安装，这样您的用户在查看报表时，就不会被要求注册他们的 Crystal 版本。
具体操作步骤：
1. 打开 Windows 应用程序。
在解决方案资源管理器中，右击 Windows 应用程序解决方案，指向“添加”，然后单击“新建项目”。
在“添加新项目”对话框中，选择“项目类型”窗格中的“安装和部署项目”，然后选择“模板”窗格中的“安装项目”。单击“确定”按钮。
在解决方案资源管理中，右击安装项目，指向“添加”，然后单击“项目输出”。
在“添加项目输出组”中，选择“主输出”，然后单击“确定”。
将自动添加所有依赖项，如 Managed.msm。
在解决方案资源管理器中，右击安装项目，指向“添加”，然后单击“合并模块”。
在“添加模块”对话框中，选择下列要添加到安装项目的合并模块，然后单击“打开”：
Database_Access.msm
Database_Access_enu.msm
regwiz.msm
VC_CRT.msm、VC_STL.msm（ 如果您部署的 Windows 应用程序使用 ADO.NET 数据集，则还需要包括 VC_CRT 和 VC_STL 合并模块）
在解决方案资源管理器中，右击 regwiz.msm 文件，然后选择“属性”。
在“属性”窗口中，展开 MergeModuleProperties，然后在“许可证密钥”属性框中输入一个有效的许可证密钥（密钥AAP5GKS0000GDE100DS）。
注意 每当部署 Crystal Reports 应用程序时，必须提供许可证密钥。
从“生成”菜单中，选择“生成解决方案”以生成应用程序。
按照上述步骤制作MSI安装文件，再次部署到目标机器（当部署到客户机或服务器时，应始终确保该计算机安装了 .NET Framework）。同样是安装到上述win98第二版，win2000 server，win xp professional这三台机器，结果是：
1. win98第二版，win xp professional这两台机器上运行正常，报表显示正常，报表导出也正常。
2. win2000 server机器上安装正常，显示报表正常，可是一旦点击了报表显示器中的导出图标，整个程序就死掉了，在任务管理器显示“未响应”，只能强行关掉。
这个结果勉强还可以接受，大不了这个程序不在win2000运行就是了。不过又发现一个新的问题，就是导出的word文档跟在报表显示器中显示的不是严格一致的，有一些差别，而且这个差别到了不可忍受的地步：
1. 在报表显示器中表格中的文字显示正常，在word中这些表格中的文字被转换成图文框中的，可是转换的图文框高度小了，导致了显示的文字的下面有一小部分显示不出来，效果就是一行文字都被吃掉了下面一部分。
2. 一张报表在报表显示器中显示的正好是一页纸，边距都很准确，可是导出的word文档，报表的内容的尾部跑到了页面以外。在设计crystal报表时页面设置是A4的，估计是导出到word文档时纸张的尺寸变了，不是A4了，而且导出的word文档的“页面设置”是暗的，不允许修改。
而这个软件中的报表一定是要导出到word的，这样的导出效果是不能接受的，于是想到是不是可是升级到crystal9 试试看。
crystal9是完全支持dotnet的，Crystal Reports 9 将其功能整合到了 Visual Studio .NET 集成开发环境 (IDE) 中，代替原先Crystal Reports for .net，从而增强了 Visual Studio .NET (VS .NET) 的开发效能。
安装了Crystal Report 9 Advanced Edtion 中文版，看vs.net的帮助中关于，看到crystal的信息显示为：Crystal Reports 9 for Visual Studio .NET，升级成功。
重新编译程序，在开发机器上运行程序，报表显示正常，主要是要看导出word文档显示是否正常，在报表显示器中点击导出按钮，导出word文档，结果是word文档显示同报表显示器中显示的报表一模一样，心中暗喜，问题解决了。
OK，现在要到部署的问题了。
判断一个字符串是否全是数字的多种方法及其性能比较-C#实现
[ 2005/06/09 22:27 | by ipaddr ]
2005/06/09 22:27 | by ipaddr ]
在编程的时候，经常遇到要判断一个字符串中的字符是否全部是数字(0-9)，本来是一个很容易实现的功能，但程序员首先会想到的是，这样简单的功能有没有现成的函数可以用呢？VB.NET中有个IsNumeric(object)，C#中只有判断单个字符的Char.IsNumber()，IsNumeric可以判断double类型的数字字符串，但无法排除正负号和小数点，如果判断字符串是否是一个数的话用它挺合适，但不能用来判断字符串是否全部由数字组成的。没现成的方法了，只好自己写函数：
public static bool IsNum(String str)
{
for(int i=0;i
if(!Char.IsNumber(str,i))
return false;
}
return true;
}
或用正则表达式："^\d+$"
还可以用Int32.Parse()抛出的Exception来判断：
try
{
Int32.Parse(toBeTested);
}
catch
{
//发生了异常，那么就不是数字了。
}
那么哪一种方法最好呢？各有优劣。我顺手写了一个程序对每一种方法所需要的时间进行了测试。测试程序Main()内容如下：
Regex isNumeric = new Regex(@"^\d+$");
int times = 10000000;
int start, end;
int i;
string toBeTested = "6741s";
#region Test user function
start = System.Environment.TickCount;
for(i=0; i
TimingTest.IsNum(toBeTested);
}
end = System.Environment.TickCount;
Console.WriteLine("User function Time: " + (end-start)/1000.0 + " Seconds");
#endregion
#region Test Regular Expression
start = System.Environment.TickCount;
for(i=0; i
isNumeric.IsMatch(toBeTested);
}
end = System.Environment.TickCount;
Console.WriteLine("Regular Expression Time: " + (end-start)/1000.0 + " Seconds");
#endregion
#region Test Exception
start = System.Environment.TickCount;
for(i=0; i
try
{
Int32.Parse(toBeTested);
}
catch
{
//发生了异常，那么就不是数字了。
}
}
end = System.Environment.TickCount;
Console.WriteLine("Exception Time: " + (end-start)/10.0 + " Seconds");
#endregion
#region Test VB.NET IsNumeric()
start = System.Environment.TickCount;
for(i=0; i
Microsoft.VisualBasic.Information.IsNumeric(toBeTested);
}
end = System.Environment.TickCount;
Console.WriteLine("VB.NET IsNumeric() Time: " + (end-start)/100.0 + " Seconds");
#endregion
因为Exception所用的时间太长，所以只测试了1/100，这样不太严谨，但是数量级不会错的。
三次运行的结果是：
User function Time: 1.938 Seconds
Regular Expression Time: 11.921 Seconds
Exception Time: 600 Seconds
VB.NET IsNumeric() Time: 40.797 Seconds
User function Time: 1.953 Seconds
Regular Expression Time: 12.016 Seconds
Exception Time: 590.6 Seconds
VB.NET IsNumeric() Time: 40 Seconds
User function Time: 2.000 Seconds
Regular Expression Time: 12 Seconds
Exception Time: 595.3 Seconds
VB.NET IsNumeric() Time: 39.69 Seconds
平均时间：
1.964
11.979
595.3
40.162
速度之比依次约为：303 : 49.7 : 1 : 14.82
结果很明显，自定义函数速度最快，异常的速度最慢。假如不需要抛异常的话string toBeTested = "67412";结果就成了：
User function Time: 1.922 Seconds
Regular Expression Time: 9.64 Seconds
Exception Time: 3.1 Seconds
VB.NET IsNumeric() Time: 39.07 Seconds
速度之比依次约为：20.33 : 4.05 : 12.60 : 1
结论：
自定义函数可以获得最大的灵活性和最高的性能，而且复杂性也不高，是最佳的方法。
正则表达式法和IsNumeric速度在同一个数量级上，但正则表达式可以确定一种字符串的格式，比如规定一定要有或没有小数点等，而IsNumeric无法做到。
使用异常是应该避免的。建议仅把Exception作为处理异常的一种手段，而不是作为控制流程的一种手段。测试也表明，当有异常抛出时，要消耗大量的资源。
IsNumeric是现成的函数，用起来最省事，只能判断所给的参数是否是数值（boolean/byte/int16/int32/int64/single/double/decimal），无法作进一步的要求（是否有小数点等）。但IsNumeric的参数是object，不局限于string。
写到这里，我不禁想，还有没有比自定义函数更快的方法呢？答案是肯定的。在前面的自定义函数中，用的是Char.IsNumber()函数，这个函数不仅能判断标准ASCII码中的'1'，甚至对全角中文的'１'的判断也是true，可见Char.IsNumber()判断的是所有的Unicode字符中的数字，其他语言中的数字也包括了。假如我们只允许ASCII中的'1'的话，我们可以这样改：
public static bool IsNum(String str)
{
for(int i=0;i
if(str[i]<'0' || str[i]>'9')
return false;
}
return true;
}
测试结果也令我吃惊，这样比原来的IsNum速度提高了近10倍，平均执行时间是0.205秒！
结果全部出来了，该怎样选择大家心里肯定已经有数了，我也不需要再说什么了。
public static bool IsNum(String str)
{
for(int i=0;i
if(!Char.IsNumber(str,i))
return false;
}
return true;
}
或用正则表达式："^\d+$"
还可以用Int32.Parse()抛出的Exception来判断：
try
{
Int32.Parse(toBeTested);
}
catch
{
//发生了异常，那么就不是数字了。
}
那么哪一种方法最好呢？各有优劣。我顺手写了一个程序对每一种方法所需要的时间进行了测试。测试程序Main()内容如下：
Regex isNumeric = new Regex(@"^\d+$");
int times = 10000000;
int start, end;
int i;
string toBeTested = "6741s";
#region Test user function
start = System.Environment.TickCount;
for(i=0; i
TimingTest.IsNum(toBeTested);
}
end = System.Environment.TickCount;
Console.WriteLine("User function Time: " + (end-start)/1000.0 + " Seconds");
#endregion
#region Test Regular Expression
start = System.Environment.TickCount;
for(i=0; i
isNumeric.IsMatch(toBeTested);
}
end = System.Environment.TickCount;
Console.WriteLine("Regular Expression Time: " + (end-start)/1000.0 + " Seconds");
#endregion
#region Test Exception
start = System.Environment.TickCount;
for(i=0; i
try
{
Int32.Parse(toBeTested);
}
catch
{
//发生了异常，那么就不是数字了。
}
}
end = System.Environment.TickCount;
Console.WriteLine("Exception Time: " + (end-start)/10.0 + " Seconds");
#endregion
#region Test VB.NET IsNumeric()
start = System.Environment.TickCount;
for(i=0; i
Microsoft.VisualBasic.Information.IsNumeric(toBeTested);
}
end = System.Environment.TickCount;
Console.WriteLine("VB.NET IsNumeric() Time: " + (end-start)/100.0 + " Seconds");
#endregion
因为Exception所用的时间太长，所以只测试了1/100，这样不太严谨，但是数量级不会错的。
三次运行的结果是：
User function Time: 1.938 Seconds
Regular Expression Time: 11.921 Seconds
Exception Time: 600 Seconds
VB.NET IsNumeric() Time: 40.797 Seconds
User function Time: 1.953 Seconds
Regular Expression Time: 12.016 Seconds
Exception Time: 590.6 Seconds
VB.NET IsNumeric() Time: 40 Seconds
User function Time: 2.000 Seconds
Regular Expression Time: 12 Seconds
Exception Time: 595.3 Seconds
VB.NET IsNumeric() Time: 39.69 Seconds
平均时间：
1.964
11.979
595.3
40.162
速度之比依次约为：303 : 49.7 : 1 : 14.82
结果很明显，自定义函数速度最快，异常的速度最慢。假如不需要抛异常的话string toBeTested = "67412";结果就成了：
User function Time: 1.922 Seconds
Regular Expression Time: 9.64 Seconds
Exception Time: 3.1 Seconds
VB.NET IsNumeric() Time: 39.07 Seconds
速度之比依次约为：20.33 : 4.05 : 12.60 : 1
结论：
自定义函数可以获得最大的灵活性和最高的性能，而且复杂性也不高，是最佳的方法。
正则表达式法和IsNumeric速度在同一个数量级上，但正则表达式可以确定一种字符串的格式，比如规定一定要有或没有小数点等，而IsNumeric无法做到。
使用异常是应该避免的。建议仅把Exception作为处理异常的一种手段，而不是作为控制流程的一种手段。测试也表明，当有异常抛出时，要消耗大量的资源。
IsNumeric是现成的函数，用起来最省事，只能判断所给的参数是否是数值（boolean/byte/int16/int32/int64/single/double/decimal），无法作进一步的要求（是否有小数点等）。但IsNumeric的参数是object，不局限于string。
写到这里，我不禁想，还有没有比自定义函数更快的方法呢？答案是肯定的。在前面的自定义函数中，用的是Char.IsNumber()函数，这个函数不仅能判断标准ASCII码中的'1'，甚至对全角中文的'１'的判断也是true，可见Char.IsNumber()判断的是所有的Unicode字符中的数字，其他语言中的数字也包括了。假如我们只允许ASCII中的'1'的话，我们可以这样改：
public static bool IsNum(String str)
{
for(int i=0;i
if(str[i]<'0' || str[i]>'9')
return false;
}
return true;
}
测试结果也令我吃惊，这样比原来的IsNum速度提高了近10倍，平均执行时间是0.205秒！
结果全部出来了，该怎样选择大家心里肯定已经有数了，我也不需要再说什么了。
SQLServer更所对象所有者
[ 2005/06/09 21:50 | by ipaddr ]
2005/06/09 21:50 | by ipaddr ]
使用存储过程更改SQLServer的对象的所有者。
打开查询器，以DBO身份连接到数据库，执行存储过程sp_changeobjectowner即可，如下：
sp_changeobjectowner 'owner1.objectname' 'dbo'
其中owner1是原所有者，dbo是新所有者，objectname是对象名.
打开查询器，以DBO身份连接到数据库，执行存储过程sp_changeobjectowner即可，如下：
sp_changeobjectowner 'owner1.objectname' 'dbo'
其中owner1是原所有者，dbo是新所有者，objectname是对象名.
