今天在SQL Server的坑里跌得鼻青脸肿，折腾两三个小时，终于爬了出来，特此纪念一下，并以此明志！
背景
案发过程
业务功能扩充，需要在数据库中增加几个字段，于是直接从本地SQL Server 2008 R2连接公司SQL Server 2000，在表适当的位置插入所需字段，然后在Navicat中修改对应的视图和存储过程。
然后，奇怪的事情发生了，程序运行未报错也无错误日志，但就是出不来数据！
打断点，跟踪调试，发现程序抛了个异常，但是没有任何代码能捕获到，而且也并未层层抛出，不知道中间哪个环节被吃了！先不管是哪吃了，把异常处理了应该就没问题了，毕竟之前都是正常的。
异常是类型不兼容和类型转换错误，好嘛，开始排查存储过程调用……一切正常！
把查询的SQL输出，在Navicat中查询，也无结果！把查询条件去掉，结果出来了！排查条件吧，结果发现条件没问题！这TM就有点让人抓狂了！！！
如此这般折磨几遍之后，结果丝毫没有任何改变！法了个克！
还是先喝口水压压惊吧，然后！居然！！竟然！！！发现了不正常的东西！！！！一个布尔型的字段里居然出现了字符串！！！！！
再次排查存储过程，存储过程正常！
排查视图，视图不正常，但视图的SQL是正确的！这TM是个什么鬼情况？？？
百思不得其解！
再喝口水压压惊，把整个修改过程回忆一遍，灵光一闪，发现了点蛛丝马迹：修改视图时，只是在Navicat中确认了下视图的SQL是否正确，因为是正确的，所以并未进行修改！嗯，问题可能就是出在这里！！！
那就在SQL Server 2008 R2里看一下吧，然后就发现了真相！我只想说：去你大爷的SBSQL Server！！！
重新修改视图，问题解决！
真相
真相就是：
自作聪明的SQL Server其实SB愚蠢到令人发指！！！
罢了，还是好好说话吧。
其实问题还是出在插入字段的这操作上，正常情况下可能是不会出什么问题的，但是当遇到视图里使用SELECT a.*, b.xx, c.xx ...这种方式时，问题就来了。
Navicat中看到的还是SELECT a.*, b.xx, c.xx ...这种方式，但是在SQL Server中却变成了SELECT a.f1, a.f2, a.f3, b.xx, c.xx ...这种方式，本来这也没什么大不了的，但是偏偏在对a表插入（并非追加）字段时就出问题了，因为SQL Server自己按字段顺序把原有的字段AS成了新字段，由于插入了字段，于是后面的字段就都错位了，结果自然就是驴唇不对马嘴了！
思考
基于这次的发现，估计在SQL Server中调整字段的顺序也有可能会出现类似的情况，不过没有去测试验证，以后有时间了再说吧（不过估计不会再有时间了吧，就算有时间估计也不会去折腾讨厌的SQL Server吧）。
另外，服务器的数据库是SQL Server 2000，修改时用的是SQL Server 2008 R2，还不好就此说这是哪个版本出现的问题，也许新版本已经解决过了吧，这还是留给有心的朋友去研究吧。
最后，我只想说，MySQL它不香么？为什么要把时间浪费在SQL Server上？为什么要把生命浪费在微软这孙子上？
