终于有一个测试结果了，测试比较的分别是一个干净的10g服务端和客户端的系统，另外一个是我们正在使用的系统9i服务端和客户端
10g服务端、客户端
1、datatype：文本，sqltype：oracle=clob，editstyleid：文本
测试结果：底层oracle创建为clob类型，且平台和数据库端均可以正常保存和显示。
2、datatype：字符，editstyleid：字符串，size：32 ,isunicode:true
测试结果：（1）可以输入16个数字或者字母。
（2）可以输入8个中文字符。
3、datatype：字符，editstyleid：unicode字符串，size：32,isunicode:true
测试结果：（1）可以输入16个数字或者字母。
（2）可以输入16个中文字符。
4、datatype：字符，editstyleid：文本或者unicode文本，size：32,isunicode:true
测试结果：（1）可以输入16个数字或者字母。
（2）可以输入16个中文字符。
5、datatype：字符，editstyleid：字符串，size：32 ,isunicode:false
测试结果：（1）可以输入32个数字或者字母。
（2）可以输入10个中文字符。
6、datatype：字符，editstyleid：unicode字符串，size：32,isunicode:false
测试结果：（1）可以输入32个数字或者字母。
（2）可以输入10个中文字符。
7、datatype：字符，editstyleid：文本或者unicode文本，size：32,isunicode:false
测试结果：（1）可以输入32个数字或者字母。
（2）可以输入16个中文字符。
9i服务端、客户端;10g服务端、9i客户端
1、datatype：文本，sqltype：oracle=clob，editstyleid：文本
测试结果：底层oracle创建为clob类型，平台中可输入字符并且保存，但保存后再打开，无内容显示，底端数据库可以正常浏览数据。
2、datatype：字符，editstyleid：字符串，size：32,isunicode:true
测试结果：（1）可以输入32个数字或者字母。
（2）可以输入16个中文字符。
3、datatype：字符，editstyleid：unicode字符串，size：32,isunicode:true
测试结果：（1）可以输入32个数字或者字母。
（2）可以输入32个中文字符。
4、datatype：字符，editstyleid：文本或者unicode文本，size：32,isunicode:true
测试结果：（1）可以输入32个数字或者字母。
（2）可以输入32个中文字符。
5、datatype：字符，editstyleid：字符串，size：32,isunicode:false
测试结果：（1）可以输入32个数字或者字母。
（2）可以输入10个中文字符。
6、datatype：字符，editstyleid：unicode字符串，size：32,isunicode:false
测试结果：（1）可以输入32个数字或者字母。
（2）可以输入10个中文字符。
7、datatype：字符，editstyleid：文本或者unicode文本，size：32,isunicode:false
测试结果：（1）可以输入32个数字或者字母。
（2）可以输入16个中文字符。
目前我们面临的情况是：1、如果我们要解决大段文字输入的问题需要将字段设计为clob形式，那么就必须升级至10g客户端，而且我们需要输入大段文字的表格不少；
2、如果我们升级至10g客户端，那原来设计的nvarchar2类型的字段长度为32的，原来可以输入32个中文字符，10g就只能输入16个了，那么将涉及大范围的调整，这个代价是非常大的。
我现在的问题是，这个测试的结果是不是平台本身的一个设计要求，还是我们的设置或者环境不对，如果不对那么正确的设置什么？如果我们的测试结果正确，那么针对我们现在面临的问题你们能给我们提供什么解决方案？ |
发表于 2009-2-23 14:59:50
楼主