cobol写sql命令
SQL中WHERE子句中可以利用LIKE来匹配相似的数据项，当时我得到的结论是可以使用"%"来匹配字符串，在SPUFI中使用，的确可以得到字符串匹配的效果。如：
SELECT * from TEST
WHERE TESTID LIKE "CZX%";
上面这句在SPUFI中提交执行后，就可以将TEST表中所有TESTID中所有以"CZX"字符串开头的项都找到。
然而，在COBOL中执行嵌入的SQL语句的时候，"%"就只能匹配一个或空的字符了，如：
EXEC SQL
SELECT * from TEST
WHERE TESTID LIKE "CZX%"
END-EXEC.
就只能查询出以"CZX"开头的且最后长度不超过4的项。
一开始的时候我并没有注意到这个问题，因此，在匹配字符串的时候，老是查询不到预期的数据。当我最终发现这个问题的时候，也没找到该用什么符号来匹配字符串，最后，想了一个利用"%"来完成字符串匹配的方法：
1、声明一个字符串匹配的变量，长度为数据库中要匹配项长度+2，如：TESTID-FILTER全部存放"%"；
2、将从终端获得的筛选字符串,如TESTID-INPUT去掉空格后，插入到1中定义的变量的第二位；
3、得到字符串TESTID-FILTER就是用在LIKE中匹配字符串的宿主变量了。
也就是说，将终端得到的数据变成形如"%*******%%%%%%%%%%"这样的匹配字符串，用于数据库的查询。这样，就可以成功的实现查询数据库中该项包含"******"字符串的所有项。
相关文档：
下面提出了10条和DB2 SQL性能相关的10条因素：
1、提供适当的统计信息
对DB2优化管理器（otimizer）而言，如何更加有效的执行SQL语句是由存在于DB2 catalog中的统计信息决定的，优化器利用这些信息决定最优化的路径。
因此，为了保持系统能够做出最佳选择，需要经常的运行Runstats命令，来保持系统统计信息的及时有效。� ......
在SQL Server 2008下，网上以前流行的截断日志并收缩文件的方法不适合了，报语法错误。
同时因为我的数据库日志增长非常快，大概每天在1G以上，因此必须对其进行收缩。
经过在系统上的测试，感觉用SQL SERVER的维护计划更可行，现将操作方式简介如下：
注：下面的说明中也提到了使用差异备份，因为数据库文件增长也非 ......
在Types of data compression in SQL Server 2008这篇博客中， Sunil Agarwal提到了在SQL Server 2008中采用的两种压缩策略：
（1）以变长格式存储所有的定长数据类型。在本系列的上一篇文章中，我提到过在SQL Server 2005 SP2中提供的使用vardecimal类型来存储decimal/numeric数据类型以节省存储空间� ......
为什么需要数据压缩
首先可能需要讨论的问题就是为什么在存储成本不断降低的今天，微软还要煞费苦心地在SQL Server中实现并且不断改进数据压缩技术呢?
尽管存储成本已经不再是传统意义上的首要考虑因素，但是这并不代表数据库尺寸不是一个问题，因为数据库尺寸除了会影响到存储成本之外，还极大地关联到管理成本� ......
