Monthly Archives: December 2009
Oracle dblink的自动字符集转换
I think it’s a great feature of dblink, it save us a lot of time when we have to migrate ZHS16GKB database to AL32UTF8 database gradually. By using Synonym at the same time, applications don’t need to change anything when it want to read or write to our target AL32UTF8 database. If there are auto [...]
美国时代周刊评出的2009年度人物亚军：中国工人
原文如下： Person of the Year 2009Runners-Up：The Chinese Worker In China they have a word for it. baoba means “protect eight,” the 8% annual economic growth rate that officials believe is critical to ensuring social stability. A year ago, many thought hitting such a figure in 2009 was a pipe dream. But China has done it, [...]
茅台集团的工作原则
以下内容摘自2009年12月17日大河报的A05版广告： 我们的一切工作围绕“三个有利于”，即“有利于国人都能喝上茅台酒，有利于让合作伙伴都能通过白金酒（白酒）赚钱，有利于企业发展”。 如何远大的目标，我真有点担心，不喝酒的我，是不是要被喝茅台酒了？
搞清楚一个关于“SAXException 未找到外部实体”的问题
一个应用程序新发版后，无法正常使用，从系统日志中查看下面的错误： Caused by: org.xml.sax.SAXException: Fatal Error: URI=null Line=5: 未找到外部实体“http://ibatis.apache.org/dtd/sql-map-2.dtd”。 根据发版前后更改内容的对比，很快排查出原因可能出在新加的iBatis配置文件，原来的配置文件中DOCTYPE部分对应的：http://www.ibatis.com/dtd/sql-map-2.dtd，但具体原因是什么？ 在使用SAX解析XML文件的时候，会根据DOCTYPE中的定义的DTD验证XML文件的合法性，但是iBatis的XML配置文件中DOCTYPE中DTD文件地址是个公网地址，那么对不能上互联网的情况下如何处理呢？ 在IBM DW的这篇文章中有一个解决方案，可以在解析XML的时候设定自己的EntityResolver，将公网地址映射到本地地址。下面是iBatis 2.3中实现类关键代码： public class SqlMapClasspathEntityResolver implements EntityResolver { private static final String SQL_MAP_CONFIG_DTD = “com/ibatis/sqlmap/engine/builder/xml/sql-map-config-2.dtd”; private static final String SQL_MAP_DTD = “com/ibatis/sqlmap/engine/builder/xml/sql-map-2.dtd”; private static final Map doctypeMap = new HashMap(); static { doctypeMap.put(“http://www.ibatis.com/dtd/sql-map-config-2.dtd”.toUpperCase(), SQL_MAP_CONFIG_DTD); doctypeMap.put(“http://ibatis.apache.org/dtd/sql-map-config-2.dtd”.toUpperCase(), SQL_MAP_CONFIG_DTD); doctypeMap.put(“-//iBATIS.com//DTD SQL Map Config 2.0//EN”.toUpperCase(), SQL_MAP_CONFIG_DTD); doctypeMap.put(“-//ibatis.apache.org//DTD [...]
2009-12-10，抓虾网站升级了？
从昨天起，我使用的抓虾阅读器经常出现下面的情况，订阅的内容无法正常显示，难道是升级了？ 顺便说一句，我发现阅读器工作不正常后，在界面上找了半天，也没发现在哪里能够反馈这个信息，难道抓虾团队没有考虑这个问题？我用当当网站搜索图书的时候，页面左下角有个直接填写反馈意见的地方，我觉得这个设置还是挺贴心的。 ps: 2009-12-14，清除IE缓存后，好像一切功能都正常了，难道是有什么js文件因为缓存的原因没有更新？
发现Open Sql转换为Oracle Native Sql的一个问题
ABAP代码：SELECT *FROMBKPFWHERE BUKRS = ’1000′ AND BELNR BETWEEN ’0100029201′ AND ’0100029301′ AND GJAHR = ’2009′ 经ST05跟踪后，实际转换为Oracle的查询语句：SELECT *FROM “BKPF”WHERE “MANDT” = ’300′ AND “BUKRS” = ’1000′ AND “BELNR” >= ’0100029201′ AND “BELNR” <= ’0100029301′ AND “GJAHR” = 2009注意后面代码的黑体部分少了引号，在SAP的数据字典里面，BKPF-GJAHR字段的类型为NUMC，实际在Oracle里面是VARCHAR2，Open Sql转换为Oracle Sql之后，GJAHR的实际值2009由字符类型变成了数字类型。 有什么影响呢？ 在这个语句的执行计划里面，带引号的语句，执行计划选择的索引是BKPF~0，而在SAP转换后的语句里面，执行计划选择了索引BKPF~BUT，这时候查询的速度非常慢，即使你只查询2个订单。 解决方案？ 目前还没有想到根本的解决方法。我的同事用个临时方法，他把凭证范围的号码一个罗列，把BETWEEN条件变成了IN(’0100029201′, ’0100029202′)，这样执行计划就正确的使用了BKPF~0
研究oracle字符集的记录
关于Unicode编码 Unicode是一个涵盖了目前全世界使用的所有已知字符的单一编码方案，也就是说Unicode为每一个字符提供唯一的编码。 UTF-16是unicode的16位编码方式，是一种定长多字节编码，用2个字节表示一个unicode字符，AF16UTF16是UTF-16编码字符集。 UTF-8是unicode的8位编码方式，是一种变长多字节编码，这种编码可以用1、2、3个字节表示一个unicode字符，AL32UTF8，UTF8、UTFE是UTF-8编码字符集 UTF-8就是以8位为单元对UCS进行编码。从UCS-2到UTF-8的编码方式如下： UCS-2编码(16进制) UTF-8 字节流(二进制) 0000 – 007F 0xxxxxxx 0080 – 07FF 110xxxxx 10xxxxxx 0800 – FFFF 1110xxxx 10xxxxxx 10xxxxxx 例如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间，所以肯定要用3字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 110001 001001， 用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。 查看当前session的字符编码： select userenv(‘language’) from dual; 查看数据库的字符编码 SELECT * FROM NLS_DATABASE_PARAMETERS where parameter = ‘NLS_CHARACTERSET’ 查看oracle的版本： select * FROM Product_component_version 下面的内容从Oracle数据库字符集问题解析摘抄的： 如果Oracle检查数据库与客户端的字符集设置是同样的，那么数据在客户与数据库之间的存取过程中将不发生任何转换。 而在SELECT的过程中，Oracle同样检查发现数据库与客户端的字符集设置是相同的，所以它也将存入的内容原封不动地传送到客户端，而客户端操作系统识别出这是汉字编码所以能够正确显示。 [...]
[读书笔记]enhancing_the_quality_of_abap_development_chapter8–待续
chapter 8 可维护性维护性高程序的标志：面对同一个需求，更改代码少，花费时间少。可维护性差的原因：代码可读性差，结构不合理，同一功能重复出现。为什么需要可维护性：由于需求的变更，程序需要在开发后由不同的人不断维护，而维护工作占IT预算的很大比例。 8.1 SAP标准软件的可维护性 8.1.1 OSS Notes 使用Note Assistant的好处 不要申请Change Key 自动更改源代码（FM的接口参数、ABAP Dictionary修改必须ABAP开发人员人工进行） 检查notes是否与当前的版本和补丁包匹配 检查系统中是否有应用notes的需要的前置notes，如果没有自动导入和应用。 在系统升级或打补丁包的时候，在SPAU和SPDD两个事务码中，可以检测已经应用的nots哪些是新版本仍需使用的，并自动应用这些notes 8.1.2 客户修改 SAP预置的修改方式，这要做升级后用户的修改和SAP标准程序仍可以和平共处。 USER EXIT: 在软件预定的位置，引用一个在INCLUDE文件中的子程序，例如MV45AFZZ Ehancement：R3 3.1引入，使用SMOD/CMOD管理，在系统中以Function Moudule的方式体现，在标准程序中使用CALL CUSTOMER-FUNCTION调用。Ehancement以项目的方式组织、激活和禁用。在系统升级时，可以临时禁用Ehancement测试标准功能是否按照期待的方式运行。 BADI: 以面向对象方式实现，可以由第三方公司创建，使用SE18/SE19管理。如果设置为multiple use，可以有多个活动的Implementation。使用filter功能，可以在运行时从多个Implementation中进行选择执行。 修改SAP系统源代码，升级后由于SAP修改了源代码，可能已做的修改无法正常运行。 尽可能使用Modification Assistant修改源代码，这样在升级的使用SE95可以管理所有的Modification。使用Modification Assistant的修改，可以在SPAU中系统自动识别出来，如果新版本允许此修改，这个修改可以重新应用。 尽量在SAP源程序修改少量代码，具体的实现放在INCLUDE子程序中。 8.2 自开发ABAP软件的可维护性8.2.1 Separating Different Actions, 不知道如何翻译，实际的含义就是模块化程序的可维护性主要取决于程序的组织方式，有经验的开发人员会将处理语句分组划分，封装到form，function module或method中。子程序的命名应该是自解释的，比较好的方式是动词+名词的命名，如read_data, process_date。备注：个人认为作者的举例不恰当，规则是对的，但是太简单，需要细化。报表程序的可重用性：一般情况下，报表输出部分不应该和数据的选择、处理、更新部分混在一起，否则程序无法重用。最好使用Function Moudle的方式进行封装，目前SAP的web话报表大多是使用了RFC技术，逐渐使用了一些method的方式。module pool程序的可维护性：与报表重用的原则是一致，但更加困难。原因是module pool程序的组织方式把响应界面和业务逻辑代码经常混在一起。module pool程序web化的是不合算的（成本太高），新的替代webdynpro技术会强制分离界面处理和业务逻辑代码。 8.2.2 提高可读性命名规则：不要需求完美的命名规则，更重要的是开发团队持续遵守同一规则。命名规则可以参考abap开发之外的领域。
记录一下权限对象相关的几个事务码
SU20: 维护授权字段 SU21: 维护权限对象 SU24: 维护权限对象和事务码的关系
《使用Javascript动态创建表格，不同的方法，巨大的运行时间差异！》的继续讨论
此篇文章为《使用Javascript动态创建表格，不同的方法，巨大的运行时间差异！》的继续讨论，原文章地址为：http://abaper.blogbus.com/logs/8278500.html 目标：生成一个2000*5的表格，每个单元格的内容是行号+逗号+列号 方法一：使用createElement生成表格，使用insertRow和insertCell方法生成行列，单元格的内容使用innerHTML属性进行填充。 方法二：使用createElement生成表格，使用CreateElement方法生成行列，单元格的内容使用了createTextNode方法填充。 方法三：拼接表格innerHTML属性的字符串，使用字符串 += 操作符链接字符串 方法四：拼接表格innerHTML属性的字符串，各个字符串追加数组里面，最后调用数组的join方法生成目标字符串。 —————————————————————————————————- 根据dofy网友的反馈，重新做了测试。 ff下没有反映是因为有脚本错误，insertRow，insertCell两个方法在ff中必须带参数，我已经修改了原来的测试代码。 对我本机有环境的几个浏览器进行了重新测试，结果如下： 浏览器 方法一 方法二 方法三 方法四 IE 7 31503 1749 6713 312 FF 3.0.10 1128 470 277 224 chrome 3.0.195.33 154 87 157 185 测试结果总结： 1、对方法一中使用标准DOM对表格操作方法的支持中，IE7的性能最差。 2、ff 3和chrome 3对字符串的“+”操作都做了优化，在chrome下面“+”操作的性能甚至比array.join()还好，这点是我没有想到的。和在Java中虚拟机对“+”操作的优化类似，我感觉以后以牺牲代码可读性进行优化的必要性变得越来越小。 3、chrome的性能确实很强，尤其是对方法二使用的createElement类方法的支持。
Feed订阅