SQL SERVER 2005 用户登录时报18456错误
[问题]
最近突然发现SQL SERVER 身份验证方式无法正常登录了，总是报18456错误，而windows 用户可以正常登录。
[解决方法]
在网上搜了一下，那些方法都不能解决问题，于是回想最近在服务器上做的一些操作：一、更改机器名称；二、针对蠕虫病毒较多，关闭了一些潜在威胁端口如135、445、137：139。
于是先恢复机器名称，重启机器，问题依旧；再打开135、137：139端口，重启机器后，登录正常。
[思考]
服务器IIS、SQL SERVER 2005数据库等应用对135端口（DCOM服务）、137：139（ NetBios服务）有依赖关系，如果关闭了这些端口，就会影响正常的应用操作，产生一些莫名其妙的错误。
相关文档：
1.查询的模糊匹配
尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用，最好不要用.
解决办法:
其实只需要对该脚本略做改进，查询速度便会提高近百倍。改进方法如下：
a、修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列� ......
*
提供两种版本的OutLook邮件发送方式
有疑问联系作者: zlp321001@hotmail.com
*/
A:利用OutLook2003发送邮件
----------------------------------------------------------------------
/
*测试环境: windowx Xp
OutLook: OutLook 2003
测试的电子邮件: zlp321001@126.com
/
第一步骤：建配置文件
......
最近在找一次sql查询的无限分类查询的设计，网上找了一下这个数据表的设计很有特色，
不用递归，依靠个简单SQL语句就能列出菜单，看看这个数据表怎么设计的，并对下面的数据表结构的查询进行分析.
数据库字段大概如下：
-----------------------------------------------------------------------------------
id ......
declare @dfname varchar(50)
select @dfname=a.name
from sysobjects a
inner join syscomments b on a.id=b.id
inner join sysconstraints ......
作为一个B/S开发者，或多或少都得和数据库打交道，而对数据库的操作归根到底都是query语句，所有到最后都是为了查询，那么查看sql性能又成了我们开发中的一件趣事。下面简单介绍下sql_trace的使用：
alter session set sql_trace =true ;--打开sql_trace
select * from (select * from t order by id) where rownum <= ......
