先看下使用mouseout的效果：

我们发现使用mouseout时，鼠标只要在容器里一移动，就被出发了hide()，其实是因为mouseout事件也会影响到子元素，也就是事件可能被同时绑定到了该容器的子元素上，所以鼠标移出每个子元素也都会触发我们的hide()。

经过网上一番调研~从jQuery 1.3开始新增了2个mouse事件，mouseenter和mouseleave。现在我们使用mouseleave事件，这个事件在jQuery手册上好像并没有提到…囧
我们来看一下mouseleave事件是否能够解决这个问题。

好了，我们的问题解决了，需要的朋友各取所需吧。

本文参考了jquery中解决div mouseout事件冒泡的问题

.transparent{
filter:alpha(opacity=60);  /*支持 IE 浏览器*/
-moz-opacity:0.60; /*支持 FireFox 浏览器*/
opacity:0.60;  /*支持 Chrome, Opera, Safari 等浏览器*/
}

那么很显然，我们就只能换个思路，把这个input元素复制一个，然后将原来的删除。
在IE下复制元素的时候，其中的值是不会被复制的，所以就达到了清空文件域的目的了。
而在Firefox下，其中的值也会被一同复制，那么我们就顺便清空一下就做到兼容了。
代码如下：

var file = $(":file");
file.after(file.clone().val(""));
file.remove();

使用表单文件域（input type=”file”）时，在PostBack中使用Request.Files获取不到文件。研究了半天，发现在input标签中使用runat=”server”后，是能够正常获取的。但是为了前端的元素ID不被修改，我尽可能不使用runat=”server”。

网上查阅了一下，最终让我找到了原因。用了高级货之后，忘本了呵呵。

要让form能够传递文件的话，必须要在form标签中加入enctype=”multipart/form-data”

<form enctype="multipart/form-data" ID="form1" runat="server">
      <input type="file" name="filename" />
</form>

在input 中使用了runat=”server”，那么ASP.NET会自动处理这些事情，而如果我们要自己DIY，就得记住这些啦！

测试了各种可能性，最后我保证了aspx与html也输出完全一致（内容本来就一样，就是格式不同），不过仍然失败。

排除了各种可能，判断很有可能是VS在输出aspx的时候出现了问题。网上查阅了一下，发现果然如此。

原文：

要你原先做的html+css没有问题的话，改为aspx后，.net环境在编译后让html的编码格式改为了utf-8。而你的css文件没有进行相应的变更就会出现css失效的问题。

仔细检查css文件是否出现乱码，最简单的方法就是先将css文件中的中文注释删除掉。

or 在web.config文件中加入下面代码：

<globalization requestEncoding=”gb2312″ responseEncoding=”gb2312″/>

原文地址：http://blog.csdn.net/ytmf007/archive/2009/07/20/4363348.aspx

 

经过测试，在Web.Config中的<system.web>中加入以上代码，页面布局恢复正常。:lol

既然是编码问题，我检查了CSS，全都是ANSI编码，并且在其中混有中文注释(-_-)，罪魁祸首找到了。当然了，配置web.config是一劳永逸的方法，所以推荐使用此方法。

近日忙于求职，所以博客也很久没更新了。不过由于最近正在学习ASP.NET，所以还是有很多问题需要记录的。

span{display: block; width: 110px; height: 40px;}
span:hover{background: 0 -40px;}
span.button-1{background:url(../images/tabs/button_1.png);}

这样测试出来的结果跟我预期的不一样，我想在span.button-1定义背景图片，然后在鼠标经过时hover显示悬停效果。本应该是会移到背景的第40像素开始显示，可是仍然只显示原始图像。
经过多次测试，终于发现是由于伪类的书写顺序不正确造成的。网上查阅了一下资料，的确伪类有明确的书写顺序规定，如果错了的话就可能造成显示结果不正确。
后来分析一下我的CSS，发现可能是由于最后一行button-1的样式把hover的background又给覆盖了。于是把伪类放到最后，也就是必须将伪类写在本身选择器之后。问题解决。

虽然我的这个问题和伪类之间的顺序并不是很相关，但是这些伪类之间的顺序还是值得关注一下的，省的以后又出现同样的问题。
顺序如下：

a:link
a:visited
a:hover
a:active

总结一下就是LVHA，听说这个叫爱恨原则，LoVe/HAte，便于记忆吧呵呵。

今天在逛dospy的时候看到好多关于“S60智能手机短信息功能假死”的文章，基本上都是转来转去抄来抄去的，没有什么具体的原理也为了安全考虑没有公布攻击方法，不过这个对于搜索引擎主导地位的今天，只要被公开了总归能被搜到。

找到一篇文章：Nokia S60 SMS/MMS (Curse of Silence) Denial of Service Vulnerability

全部是英文的，应该也是转载国外的文章，不过写作很规范，让人一目了然。

大概就是说的S60部分版本的系统存在漏洞，如果一条短信息以电子邮件格式发送，并包含超过32个字符的email地址就会被锁死，无法接收新的短信。

我的N71是S60 3rd，我只知道是OS9.1，具体版本我也不高兴去了解了，所以是在受影响范围中。

试验了一下，果然是有效果的，N71上的具体表现为在接受到此类短信后，不会有正常的提示，直接弹出“WatcherMainThread”的错误提示，并且会不断提示。

因为已经作好了再一次“*#7370#“（软格的命令）的准备，所以放心大胆地做了试验。因为最后有工具可以清除和修复，所以根本不用担心。

下面是专杀工具，下载的时候看好自己是什么版本的系统。

CurseSMS
   English (S60 Symbian 7/8): Download Now
   English (S60 Symbian 9): Download Now

此漏洞危害面确实很广，如果有人吃饱了没事恶作剧差不多很多人都要受影响。以后我手机常备这个工具，以防不测。。

经本人亲自测试，成功～记得清除完了要重启计算机，否则还是报错的！

中文部分就在类别处，由于我只是将URL中需要的部分用正则表达式提取出来然后Rewrite到响应的页面即可，所以不存在匹配中文这种稍微有点复杂的正则表达式。

不过这条规则使用以后，重写后显示的页面出现了问题，于是加了个echo显示传入的“类别”。

发现是乱码，然而如果我在浏览器中直接输入重写前的网址，中文是能够显示的，因此这里在URL中可能存在编码不统一的问题。

URL中其实也是有编码的，百度和谷歌识别出来的URL就是用了不同的编码，Google是UTF8的，而百度是GB2312的，所以对于那些URL中包含中文的朋友来说的确是挺痛苦的，鱼与熊掌不可兼得。

由于这次我使用的是GBK编码，所以URL应该也是属于GB2312的，然而经过资料查阅，发现不管是Apache还是ISAPI_Rewrite，URL均识别的是UTF8编码的，因此，这里就出现了乱码。

需要说的是，这里使用UNICODE过的URL也是没用的，因为编码不同，UNICODE出来的URL地址也是不同的，所以最终的解决办法，也只有是将网页转换成UTF8编码了。

不过好像没有效果，当网站载入一遍之后又出现了PHPCMS 的默认Favicon。

于是我检查了好几遍网页的HTML代码，但是并没有发现定义网站Favicon的代码。

<link rel="shortcut icon" href="favicon.ico" type="image/x-icon" />

最后一个办法就是去找到这个.ico文件，然后删除咯～在网站根目录发现Favicon.ico，个人认为浏览器会默认读取网站根目录下的Favicon.ico来作为网站的favicon，这样是不用在HTML中定义的。

也许是我不了解.Net，不知道为什么表单中input的name都是带有冒号的。。。比如：Login1:tbName

这个名称很明显，一放到javascript中就不好使了，我alert一下都不行哎。。。人家根本不认冒号的嘛

alert(document.myform.Login1:tbName.value);

去掉冒号一切正常，所以断定就是冒号的问题。谷歌一下（最近开始慢慢不用百度了），搜form冒号，出来的基本上都是冒号的作用什么的，貌似没有人遇到过我这样的问题。。。

于是就得想其他办法来读取这个input文本的value了。正好看到一段代码中有用getElementById的，于是就尝试了一下。由于我基本属于没有学过javascript的，所以平时都只是看看改改别人的代码，只懂得些皮毛。所以要用语句都得去查查手册什么的～

网上找到一些比较有用的方法：

document.getElementById("link").href;
document.getElementById("link").target;
document.getElementById("img").src;
document.getElementById("img").width;
document.getElementById("img").height;
document.getElementById("input").value;
document.getElementById("div").innerHTML;

这里也可以读取input的value，不过是通过id来获取的，所以这样就不会影响到表单数据的传递，而达到我对表单验证的目的了。

为了尽可能少地修改每个页面，在导航的页面中每个<a>标签中都插入了一个ASP的数组，并对每个链接进行了编号，然后每次打开页面时，对URL进行判断，然后在符合条件的数组元素中赋予”class=current”的值，这样就达到目的了。

说起来简单，但是URL判断的时候还是要动点脑筋的，最近URL重写用得比较多，因此对正则表达式略有了解，于是就想到了在这里用正则表达式来匹配出我想要的部分。

使用Request.ServerVariables(“URL”)所返回的URL形式为：/dir/file.ext
我将每个版块的文件放在了不同的文件夹中，因此，我只要对/dir/进行判断就能分别显示不同的标签了。

下面给出我写的代码，主要就是想说一下ASP中正则表达式的用法。

Dim Reg, Str
  Set Reg = New RegExp   '建立正则表达式对象
  Reg.Pattern = "/((.*)+)/"   '设置正则表达式
  Reg.Global = True   '是否全局匹配，也就是匹配一次还是匹配多次
  Reg.IgnoreCase = True   '忽略大小写
  Set Str = Reg.Execute(rURL)   '进行匹配查找
  If Str.Count > 0 Then   'Str.Count 表示找到的匹配次数
   URL = Str(0)   '数组中就是找到的匹配文本了
  End If

下面这段是我在网上找到的，对于我在开发过程中有很大的帮助：

集合对象(Matches)的使用：
Set Matches=regEx.Execute(str) ‘对str进行搜索,返回匹配到的Matches集合
属性：
Matches.Count ‘匹配到的个数
Matches.Item(i) ‘第i个匹配到的字符串
注意:Matches.Item(i)=Matches(i).Value=Matches(i)

引用自：http://hi.baidu.com/wfyeshi/blog/item/d5dce410334536ffc3ce79d7.html

这些对匹配后的结果处理上有帮助。

用这段代码，可以将/dir/file.ext中的/dir/给匹配出来，然后只要在后面用一个数组来进行匹配就能实现我的当前页面标签亮起的功能了，这个是我自己想的方法呵呵，不知道网上是不是有更好的方法呢。当然上面举的那段代码仅仅是最简单的实现匹配而已，后面的结果处理就自己发挥的了，还要考虑到多层目录以及根目录的情况，这里就不给出实例说明了。

对IIS站点进行操作（停止、启动、暂停）时，出现错误：服务器没有及时响应启动或控制请求
对IIS进行的参数修改均无法及时生效，需要重启IIS才生效。

由于上次在重新安装了IIS以后并未彻底解决这个问题，仍然会出现IIS无响应，因此，这次决定重新再彻底清理一遍。

还是老样子把IIS卸载了重新安装，这次把星外的主控端被控端也统统卸载了再安装。并且把启用磁盘配额的那个硬盘分区也格式化了一下（当然用户数据是备份到其他盘的），格式化以后把原先的一些乱七八糟的磁盘配额项残留都给清除了（因为直接删除配额项好像有点问题，所以选择了格式化）。

然后按照步骤一步一步安装好星外主控端被控端以及IIS，一切看起来就是全新的了，然后恢复所有用户站点。接着配置一切自己手动配置的东西。结果还是有问题～郁闷

这下如果实在不行我就得去机房格式化系统了，不过不甘心啊，于是开始一步一步排查，想到了安全模式的思想，就是不加载任何东西，也不设置什么，直接用默认的配置。

果然有效，说明是我自己手动加载的一些东西起了冲突，最后找到问题所在！

原来是ISAPI中加载的wp-url-rewriting.dll，注意了，这个并不是我上次推荐的WordPress URL Rewrite，而是上星期在网上看到的一个国人开发的URL Rewriting for WordPress，因为这个ISAPI组件我还在自己测试中，所以并未及时推荐。

这个ISAPI可能与星外主控端存在冲突，在不加载后，目前测试下来仍然是正常的，所以应该就是这个问题了。于是换成老外的那个。这个那么微小的问题，害得我重装了2遍IIS，不过也好，第二次把服务器都给清理了一下～

出现错误：服务器没有及时响应启动或控制请求

问了星外的客服，他们给我的答案就是，可能你的IIS有问题或者系统有问题，叫我检查一遍磁盘～检查完了无明显改善。也不能怪人家，是你的服务器出的疑难杂症，人家只能给出建议嘛，我还是可以理解的，大家都是搞技术的～

一直在查这个问题，由于从原来的依然主机管理系统转换到现在的星外虚拟主机管理系统，首先怀疑可能是由于数据残留造成的错误。有一些应用程序池存在错误，虽然是停止的，不过不能删除。DefaultAppPool池应用程序列表显示“<站点 #1>。。。“根本没有这个站点，已经混乱了～我想这个问题应该很少有人碰到，我也无法删除这个错误的应用程序池，因此还是只能选择重装IIS了。

重装了一下IIS，彻底清理一下。由于更换成了星外虚拟主机管理系统，知识库相当庞大，也想得很周到，基本上你能提出来的问题都已经有了。根据《重新安装2003操作系统的注意事项》（在星外的正版知识库中，需要登录，所以就不给链接了），安装好主控端和受控端后，在管理区中进行用户重建。

第一次重建的时候出现了错误，因为我并不是重装整个系统，因此系统中的用户仍然存在，因此先把原有的用户删除。然后再次开始重建，这次重建花了相当长的时间，可能5－10分钟，因为我只有19个站点，15个用户，所以还是比较快的。随后就是重新分配权限，重新磁盘配额之类的，反正全自动的（星外NB）。

有些是自己配置的东西就需要重新配置一下，不过也不复杂，主要就是Blog的虚拟目录以及WordPress URL Rewrite以及ISAPI_Rewrite的加载。

这里不得不称赞星外虚拟主机管理系统的强大恢复能力，这点他们做得非常好，用户不用担心是否会有站点配置错误或者数据丢失之类的，完全傻瓜式的，怪不得人家说“买星外不后悔”（我不是星外的托，我是客户，这是我真实感受，虽然界面粗糙了点，但是从功能上来说还是很强大的！界面粗糙我不担心，因为界面这东西是活的，做这行的人都会改。）

半夜里施工。。。就是怕扰民（服务器维护就是得夜深人静的时候）

不过，最后问题仍然存在还是没有解决。在后来的一次修复过程中，我找到了问题所在。请看IIS无响应问题终于解决

网上查找了一下解决方法，有官方给出的方法，但是明显不对路，不知所云。。

也找到了给/windows/system32/drivers/目录权限的解决方法，不过同样不适用，因为本来是好的，突然就不好了，怎么可能会是权限问题呢？又没人动过。

最后自己动手丰衣足食啊。。打开了WinWebMail的服务端界面，发现红色大叉，于是遍找到了原因：WinWebMail的服务端没有启动！

到服务里检查，发现启动时提示“错误1069：由于登录失败而无法启动服务。”

一检查原来是服务启动帐号出了问题，因为那天把这个没用的帐号给删除了～在登录中设置为本地系统帐户，启动成功～没有了超时错误了

今年暑假开始学习SEO的基础知识，逐渐认识到一个简短的URL地址形式对于搜索引擎来说会更友好些。因此，开始逐渐调整。

由于改变网站的URL结构对于搜索引擎来说是相当不友好的，因为他们不喜欢一个经常变动的网站（这里的变动指的是网站结构，而不是不更新网站内容）。于是，我在更改地址的时候采用了301重定向，这对于搜索引擎是友好的，也就是你告诉了搜索引擎这个页面已经更改，以后指向新的页面。

因为原先问了下高手，说URL地址形式尽量简洁，不要出现不必要的目录，比如/html/这个就是多余的，完全没有必要。（也不知道当时哪里看来的说看起来舒服点全放html目录里。。靠。。）因此，第一次调整去掉了/html/这层目录，保留了后面的年月日，也去掉了最后的.html，按照我的理解就是目录有可能会比页面有更高的权重（个人猜测呵呵）。

不过今天又看了篇文章说目录尽量少点，于是年月日看起来也是多余的了。。。最后只剩下了以文章的slug作为第一层目录，超级简洁～这个URL地址形式我看到好多高手的博客都是这样的，原来用ISAPI_Rewrite自己写规则，总是有点问题，现在用了WordPress URL Rewrite以后完全不用担心这个了，人家全自动的～

最后要说的也是最重要的就是如何做301啦，我只举几个例子，因为都是可以举一反三的东西，而且基本都没有难度（因为连我这样的都能自己写出来^_^）。关于301转向的详细内容可以看下《利用 ISAPI Rewrite 做301永久转向》，同样也是我写的～

# 这条用来去除/html/以及最后的.html
RewriteRule /html/(.*).html?$ /$1 [I,RP]
# 这条用来去除/html/
RewriteRule /html/(.*)?$ /$1 [I,RP]
# 这条用来去除.html
RewriteRule /(.*).html?$ /$1 [I,RP]
#这条用来去除/年/月/日/
RewriteRule /([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/(.*)?$ /$4 [I,RP]

因为我更改了好几次URL地址形式，所以每更改一下就写条URL重写规则，你完全可以把3条合并起来用。

注释：最后的[I,RP]表示忽略大小写以及301重定向。

顺便说一下就是最近天天观察流量统计，发现每天流量稳定在15－20之间，而且每天都有固定的几个关键字从搜索引擎带来流量( *^_^* )，说明我的文章写得好～玩笑～这些带来流量的文章在搜索引擎全是第一页的HOHO，特别是Vista修改Hosts或Lmhosts文件的方法这篇文章，每天至少有3个IP是从这里来的，而且在Google和百度的排名都在前三～

嗯，再接再厉~

完全版(Full)与简化版(Lite)的最大的区别在于可以让每个站点自定义URL重写规则（Rewrite Rule），也就是只要将写好的httpd.ini放在站点根目录，就能使用了。

大多数空间商使用的是简化版（Lite），设置了统一的规则，如果你需要设置自己的比较独特的规则，需要联系客服在全局配置中为你添加规则，然而，这个有可能会与别人的规则冲突（你规则写得不完善的话），并且规则数量较多的话，肯定是影响网站空间性能的。

选用简化版的最主要的原因就是因为是免费的，配置也简单。

下面进入正题：网上虽然有ISAPI_Rewrite 2.9 Full 完全版 的破解版本，但是也不知道这个破解版本是谁发布的，因为他根本就是掩耳盗铃。仅仅把ISRWConfig.exe进行了修改，因此你只要任意属于序列号都能注册成功。

不过经过我的使用情况来看，这个破解是无效的，你只要打开事务管理器查看日志，就会发现许多ISAPI_Rewrite发出的错误信息：Your trial license has expired.

在你未重启IIS前，ISAPI_Rewrite还是可以用的，而如果你重启了IIS以后，URL重写的功能就完全失效了。

虽然破解版的ISRWConfig.exe中显示This product is registered to…，实际上这个是假的，只是掩耳盗铃而已。根据我的观察，我认为主要的验证还是通过ISAPI_Rewrite.dll，ISRWConfig.exe的作用仅仅是一个配置工具而已，可以让你输入序列号，以及设置一些参数。而当你输入了序列号以后，就会生成一个ISAPI_Rewrite.lic，将你的用户名以及序列号保存在里面，然后每次调用ISAPI_Rewrite.dll时，就会去验证这个序列号。

由此可见，网上所谓的破解版，根本都是无效的。所以，最实际的办法还是找个正版的序列号～

由于CooSel2.0 CreateSQL这个工具相当不错，能够将Access的数据库表的结构转换成SQL Server的更加复杂的结构，也就是数据库的升迁，你不必担心由于Access的结构与SQL Server的不同而产生错误！因此，我们不需要做任何手工改动与设置，直接使用该工具生成SQL脚本后，放到SQL Server中执行查询即可。当然该工具还提供了生成ASP文件以及直接导入SQL Server方式，笔者推荐使用SQL脚本，这样便于修改脚本内容。

我想在SQL Server中执行SQL脚本应该就不用再说了吧，如果这个还不会，那你就应该在虚拟机里多操练操练，服务器可不是闹着玩的，等你熟悉了SQL Server的操作方式后，再看下面的内容。

我们尝试来分析一下使用CooSel2.0 CreateSQL生成的SQL脚本，通过修改，才能符合我们的需求（比如仅创建数据库而不添加用户）。我们现在创建一个测试数据名为data.mdb，添加2个表，并添加几个测试字段。

在脚本头部，我们看到这几行：

Create Database [data]
 go
use [data]
 go

显然，这里是在SQL Server中创建一个数据库，名为data，然后使用这个数据库。如果我们已经自行创建好了，可以把开头的2行去掉，只留下use这2行就可以了。

exec sp_addlogin 'data_login','123','data'
 go
exec sp_adduser 'data_login','data_login','db_owner'
 go

这里是创建SQL登录帐号，这些是在你用CooSel2.0 CreateSQL创建脚本时输入的，当然如果你不需要创建的话，可以随便输入，然后把这里几行删除。不过记得给你的用户添加映射。

--[data]:

CREATE TABLE [dbo].[data] (
    [ID] integer IDENTITY (1,1) not null,
   [字段1] nvarchar(255) null ,
   [字段2] integer null
  ) ON [Primary]
 go
--这里可能还有其他表
--[data]:

 Alter TABLE [dbo].[data] WITH NOCHECK ADD CONSTRAINT [PK_data] Primary Key Clustered ([ID] )  ON [Primary]
 go
--这里可能还有其他表

从这里开始就正式开始创建数据库中的表结构了，这些我们不需要改动，如果你已经创建好了结构，那么可以把这块也删除了。在Access数据库中有几个表，就会有几块这样的语句。

--[data]:
SET IDENTITY_INSERT [dbo].[data] ON
 go 

INSERT INTO [dbo].[data] ([ID],[字段1],[字段2])
 SELECT [ID],[字段1],[字段2]
 FROM OPENDATASOURCE('Microsoft.Jet.OLEDB.4.0','Data Source="C:\data.mdb"')...[data]
 go 

SET IDENTITY_INSERT [dbo].[data] Off
 go
--这里可能还有其他表

这里是插入数据的地方，会读取Access数据库中每个表中的数据然后插入到SQL Server中的相应的表中。其中Data Source=你Access在硬盘中的位置，如果是虚拟主机的话，用个ASP的探针就能很容易看到自己站点所在目录了。

好了，一个完整的SQL脚本我们就全部分析完了，你可以根据你的情况来删除不需要的部分。

如果你在执行SQL脚本以后，出现如下错误：

SQL Server 2005：
SQL Server 阻止了对组件 'Ad Hoc Distributed Queries' 的 STATEMENT'OpenRowset/OpenDatasource'
的访问，因为此组件已作为此服务器安全配置的一部分而被关闭。系统管理员可以通过使用 sp_configure 启用
'Ad Hoc Distributed Queries'。有关启用 'Ad Hoc Distributed Queries' 的详细信息，请参阅 SQL
Server 联机丛书中的 "外围应用配置器"。

那么说明你的SQL Server的Ad Hoc Distributed Queries没有开启，需要在你的SQL脚本顶部添加：

EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
EXEC sp_configure 'Ad Hoc Distributed Queries', 1;
GO
RECONFIGURE;
GO

再次执行你的SQL脚本，如果你是使用的最高权限帐号（Windwos模式或SA帐号），应该是成功的。
如果提示：

服务器: 消息 15247，级别 16，状态 1，过程 sp_configure，行 170
用户没有执行此操作的权限。
服务器: 消息 5812，级别 14，状态 1，行 1
您没有运行 RECONFIGURE 语句的权限。
服务器: 消息 15123，级别 16，状态 1，过程 sp_configure，行 79
配置选项 'Ad Hoc Distributed Queries' 不存在，也可能是高级选项。

SQL Server 2000提示：
已拒绝对 OLE DB 提供程序 'Microsoft.Jet.OLEDB.4.0' 的特殊访问。必须通过链接服务器来访问此提供程序。

说明你的帐号权限不够，需要SQL Server用户具用SystemAdministrators”服务器角色”。如果是虚拟主机，那么就麻烦你的空间商帮你做这些吧。

不过一次在群里有位朋友说Access数据库是比较慢，改用MSSQL以后速度会有所改善。

于是开始设法将现有的Access数据库导入到MSSQL 2005中。以前也尝试导入过，但是用SQL Server自带的DTS服务直接导入（先用sql脚本创建好表结构，否则会丢失标识等），会出现下列错误：

- 执行之前 (错误)
消息
错误 0xc0202009: 数据流任务: SSIS 错误代码 DTS_E_OLEDBERROR。出现 OLE DB 错误。错误代码: 0x80040E21。
已获得 OLE DB 记录。源:“Microsoft SQL Native Client” Hresult: 0x80040E21 说明:“多步 OLE DB 操作产生错误。如果可能，请检查每个 OLE DB 状态值。没有工作被完成。”。
 (SQL Server 导入和导出向导)

错误 0xc0202025: 数据流任务: 无法创建 OLE DB 取值函数。请查看列元数据是否有效。
 (SQL Server 导入和导出向导)

错误 0xc004701a: 数据流任务: 组件“目标 9 - yiran_order”(804) 在执行前阶段失败，返回的错误代码为 0xC0202025。
 (SQL Server 导入和导出向导)

而如果不用sql脚本创建结构的话，直接导入是没有问题的，这个问题在网上找了下，基本没有什么资料，而且国内用SQL Server 2005的人并不多，而且大多数开发者使用的都是Express版本，他们只注重一些开发上的问题，而对于服务器管理者来说，SQL Server 2005的技术资料并不对，因此这个问题是比较难解决的，毕竟我不是MCDBA，我只是个MCSE而已。
既然SQL Server自身的Managemeng Studio无法使用，那么我们就全部通过SQL脚本来解决，因为图形化管理器也只是将一系列的管理功能通过图形化界面来生成相应的SQL脚本来操作的罢了。

网上很辛苦地找到了一个工具～真是福音啊。这个工具的原理是通过对Access数据库的分析自动生成SQL脚本，可以包含数据，也可以只有结构。然后只要放到SQL Server中执行一下查询一个数据库就建好了。关于如何在SQL Server中执行脚本以及在执行脚本时可能会出现的一些问题，请参考用 SQL 脚本将 Access 导入 MSSQL 2000/2005 方法

下载：CooSel2.0 CreateSQL v1.06
（支持SQL Server 2000/2005）

可能解压后会提示缺少控件，COMDLG32.OCX这个文件本来并不在这个压缩包里，我是将2个合并了起来。这个应该是VB的空间，如果提示缺少这个的话就执行RegOCX.exe试试（这个我没试过～因为没提示缺少），不行就把COMDLG32.OCX复制到system32下看看吧。

如果你找到了更好的工具，也请告诉我一声吧呵呵～

写程序其实是件很苦的事情，其中会遇到一系列的问题，不过当你遇到多了，也就知道基本该怎么处理了，也就不怕了，只是烦了点而已。正因为如此，我在写程序时，碰到的一些很奇怪的问题也能很快的解决，因为我在不断遇到问题的过程中，也学会了一些解决问题的手段，比如设置断点（可能这个是桌面编程的术语，不知道Web编程有没有这一说。。）

这次遇到了一个比较麻烦的问题就是从SQL Server中读取数据。从表面上看其实并没有什么难度，但是因为之后需要用到计算，所以必须在数据类型不匹配的情况下，就遇到了一个数据类型转换的问题。

一直以来遇到类型转换我经常会碰到问题，而且经常会很莫名不知道为什么会这样，后来经过查阅了大量资料以后，总结出ASP在类型转换时需要注意的一点：被转换的数据不能为空（Null）

我们必须在对变量进行类型转换前，先做一个是否为空的判断，因为很多时候读取出来的数据可能是空的，对于整形来说，默认的应该是0，而字符串类型的确是空的，所以这样就会出现

Microsoft VBScript 运行时错误错误 '800a000d'
类型不匹配: 'Cint'

这样一来，碰到类型转换就不怕了，不过下面这种情况可能是你不太容易想到的，让我整整抓狂了一晚上了呵呵。

在使用了上面的方法以后，仍然存在问题，还是显示类型不匹配，这个又是为什么呢？我在转换前已经做了判断，还是不起作用，难道传输过来的数据不是空的吗？于是我用len()函数测试了一下，显示长度为8，晕～

明明是空的，为什么长度是8？于是直接到SQL Server企业管理器查询，找到了问题所在！原来数据库这个字段默认值为“8个空格”。。我靠！谁设计的数据库表结构，真是的，一点专业水准都没有！

问题结论：因为是8个空格，因此，转换成整形当然是“类型不匹配了”。

经过这次的经验，以后在字符串处理的时候，如果遇到某些看不见的字符难以处理的话，还是使用返回长度的函数看一下究竟有没有字符，然后再根据具体情况进行处理。