数据库服务器：SQL Server 2005

这是在第N次测试的时候发生的问题。

之前正常运行的代码，在执行一个查询的存储过程时突然报了「不能在手动或分布事务方式下创建新的连接」异常。

因为很久没有动过那个部分，所以很奇怪，怎么突然就这样了呢。

当时正好有另一台服务器，于是在那台服务器上测试了，发现是正常的，就怀疑是否服务器参数设置的关系。

但是其他人的代码都是正常的啊？前辈提醒我看下set nocount那些是否一致，检查了也是一样的。

正在一筹莫展、继续搜索的时候，前辈找到原因了。 

原来那段代码是调用了多个存储过程的，在调用这个存储过程的前一个里面没有设置set nocount on，
于是轮到调用它的时候就报错了。

查查MSDN，set nocount on如果没设置的话，就会更新@@RowCount函数，返回影响的行数。

但是这和那个错误有什么关系呢 = =

按照这个错误信息查了一下，好像多在SELECT时发生，和Cursor有关。

但是具体好难理解啊，总之先mark。

• 无法启动数据库服务器
  执行db2start提示SQL1042C 发生意外的系统错误。 SQLSTATE=57019
  
  百度了一下可能是因为许可证到期的关系。安装时已经有提示不过没注意到。
  找了个nodelock文件放到DB2安装目录/licence/下即可。
  其他错误可能：http://www.sudu.cn/info/article/articleInfo.php?aId=20635
   
• 创建数据库，设定文件夹后提示数据库路径不存在。
  
  原本以为是只能指定已存在的文件夹的关系，结果创建了还是这个错误。
  百度得到需要设置DB2_CREATE_DB_ON_PATH属性为真，
  执行指令db2set DB2_CREATE_DB_ON_PATH=YES即可。
   
• 新建用户没有地方设定密码？
  WIN下实际上是和系统用户绑定的，在管理工具-本地用户和组中设定用户密码再到DB2下创建即可。

使用链接服务器开发过程中遇到的种种问题……

最近写一个存储过程，需要一个临时的表，本想用临时表，导师说表变量速度快一些，结果用了50秒，数据量大概是百万级，后面同事换成临时表，变成20秒 - -! 在创建了SQL Server优化器建议的索引后不到1秒就跑完了 Orz。

那么什么时候该用表变量，什么时候用临时表呢？

直接转不大好，贴个网址，个人觉得总结得不错：http://topic.csdn.net/u/20100610/22/fc438413-8472-40fb-b301-39ae0b8c36c4.html

其实如其所说，直接两个都试一下就知道了 = =。
非要规律的话，按照以下应该差不多……

要使用表变量应该根据如下规则来判断：

1. 表的行数；

2. 使用表变量能够减少的重新编译次数；

3. 查询的类型和对索引或者统计信息的依赖程度；

4. 需要生用UDF,UDDT,XML的时候。

其实也就说，得从实际出发，根据具体的查询，作出具体的选择。但是，其中很关键的一点，如果表的行数非常多，使用表变量其实是更费资源的。有人提出了这样的建议：对于行数较少的情况下(小于1000行）可以使用表变量；如果行数很多（有几万行），则使用临时表。

这次SELECT TOP 4 啥啥啥 ORDER BY date DESC，结果发现给了我六条，打开access查询视图去查也是一样的，无奈百度之，原来Access用的是Jet SQL，在date字段一样的情况下Jet SQL无法分辨，于是把并列前4名的都丢给了我……

解决方案很简单 - -。。在后面加一个自动编号的order，即order by date desc, id desc之类的……

因为很懒所以想直接在数据库里设定级联关系。
本地数据库用的Access，以前都没用过外键，找来找去没看到。
百度之了解可以打开数据库工具中的关系，将表拖进去，从主键拖到外键即可创建一对多关系，
编辑时选中实施参照完整性即可设定是否要级联更新和级联删除。

原本装虚拟机里的，但是每次都开虚拟机实在是太卡了，因此便下了个200+M的express。

居然默认用8080端口，和tomcat冲突，于是百度之，原来在命令窗口里输入以下即可：

call dbms_xdb.cfg_update(updateXML(dbms_xdb.cfg_get(),'/xdbconfig/sysconfig/protocolconfig/httpconfig/http-port/text()',8081));

同理的，修改ftp端口则是修改ftpconfig/ftp-port的text()。

囧死了。。按照oracle官方的说法有：

Oracle assigns a ROWNUM value to each row as it is retrieved, before rows are sorted for an ORDER BY clause, so an ORDER BY clause normally does not affect the ROWNUM of each row. However, if an ORDER BY clause causes Oracle to use an index to access the data, Oracle may retrieve the rows in a different order than without the index, so the ROWNUMs may be different than they would be without the ORDER BY clause.

好无语。。巨讨厌。。最后为每个实体类加了一个返回排序的方法，在泛型DAO里面用。无比郁闷。ORACLE真爱搞特殊化，存储过程已经能灭杀人了连排序都…… TAT。