OleDB调用DB2存储过程字符串只支持127个……

很迷茫的错误，百度到的解决方案：

将原来的连接字符串：

"Provider=SQLOLEDB.1;Persist Security Info=False;User ID=**;PWD=**;Initial Catalog=DatabaseName;Data Source=IP"

改为：

"Provider=SQLOLEDB.1;Persist Security Info=False;User ID=**;PWD=**;Initial Catalog=DatabaseName;Data Source=IP,1433"

即可。

也就是把“Data Sourse = IP” 改为“Data Sourse = IP,端口”

很迷茫啊！！

原帖地址：http://www.cnblogs.com/hsrzyn/articles/1674362.html

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

嗯(⊙_⊙)。。很早前下歌拷到里面 部分繁体或者日文就会乱码了。。
也一直没弄封面，光溜溜的，
最近沉迷Saki，下的歌几乎都是乱码（但是为什么部Cap的就好好的呢这就是爱吧哇哈哈）
于是百度了之，大概搞定了，千千静听真是好啊！！！

乱码问题在于文字并非使用ID3v2标签，用千千静听编辑文件属性，MP3标签处写入类型选择ID3v2，编码类型为UTF-16，读取优先级为ID3v2最先即可。

封面则是在编辑文件属性的专辑封面选项卡里设定，注意要是size在128*128以下的JPEG格式图片，若超过就不能显示，小于的话会自动扩展（不过不是按比例的 - _______ -）。

最近写一个存储过程，需要一个临时的表，本想用临时表，导师说表变量速度快一些，结果用了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之类的……

嗯，么想到这么快就过了123456hits，没有截图到囧。大概是因为这几天开始校园招聘了吧，发现关键字里面很多都是XX 笔试……

那么放送一个半年前搞的Ext+DWR实现聊天的段落、、
玩这个是因为毕业设计里面有一个需要教师在线指导学生的模块，类似于聊天室，界面如下图（中的在线指导子页面）所示：

Ext用的是Ext JS Library 2.0.2，DWR则使用2.0，因为支持Server Push。

贴一段技术手册里的介绍^^：

系统中教师指导学生模块可以通过在线聊天的方式进行，该模块的实现采用了Server Push（服务器推送）技术，实时发送消息，优于现在浏览器通过AJAX轮询服务端的策略。基于Java开发的DWR框架从2.0开始提供了push功能，通过它建立的应用可以大大节省服务器的资源消耗。

DWR 2中提供的push功能是一种Comet方式，即长连接机制（long live http）。浏览器向服务器请求时，服务器一直保持着这个连接，在关闭之前都可以主动地推送数据给浏览器。下面是本系统中聊天模块的实现示例图：

  

图1-2 聊天模块实现

设计数据库，或是创建多语言网站时需要用到、、