TClientDataSet.TWideStringField问题多多，如果您在Com+下开发，不能不看(200分)

[]
在nt4.0,win98环境下,delphi5：
1.TClientDataSet.Locate在TWideString类型的字段下查找永远返回 false
2.在TWideStringField的长度很短（如2）时，字段值的修改无法被TClientDataSet.Delta
侦测到
可是编译后的执行代码放到win2000下可以正常运行
本人做过以下试验：
两个同样内容的表格，一个字段类型为TWideStringield,另一个表子段为TStringFiled
执行Locate跟踪到
dsintf.TDSCursor.LocateWithFilter(ExprParser.FilterData, ExprParser.DataSize);
TStringFiled类型上述函数返回0（成功）
但TWideStringFiled类型上述函数返回非0
检查所带入ExprParser.FilterData, ExprParser.DataSize没有区别
奇怪？
TDSCursor为接口类型，我不知道LocateWithFilter方法在哪里实现，所以无法进一步跟踪
怀疑delphi关于Unicode编译程序可能有问题，但同一个编译后的执行文件可以在win2000下正常运行
Unicode怎么啦？win2000对它的定义改变了吗？Borland早就知道它会改变？

没人回答，问相关的问题：
Clientdataset.pas使用了很多dsintf.pas声明的接口方法
这些方法不用实现代码吗？

TClientDataSet.Locate在TWideString类型的字段下查找永远返回 false
这个问题我也有碰过，不过当时没发觉是TWideString这样

有好消息：
1.对问题的重要更正：关于win200和winnt的区别，是我的误判断，它事实上是
d5和d6的midas.dll版本的区别，因为凑巧我测试的两台win2000都装了delphi6
其他几台winnt和win98装的是dephi5.为此向关心此问题的先生们致歉
2。目前的结论：
delphi5的midas.dll对TWideStringField最后一位字符变动无法为Delta侦测到
直接用delphi6的midas.dll覆盖winsys目录的文件，可使delphi5正常工作
locate,filter不能在TWideStringField使用问题仍无法解决

用TWideStringField这个到底有什么好处？

用TWideStringField这个到底有什么好处？
1.许多ADO驱动程序会把字符型字段解释为TWideStringField,如
如果你使用哦Oracle提供的ADO驱动程序访问Oracle
使用微软提供的ADO驱动程序访问Access
...
2.TWideStringField可以处理>255长度的字段，让我们尽量避免使用blob类型
3.TWideStringField属Unicode,提供完善的多语言支持，举个例子：
Oracle用"_" 表示一个任意字符，对unicode而言，它可以是一个汉字，
也可以是一个字母

win 98 不支持unicode.

有好消息：
1.对问题的重要更正：关于win200和winnt的区别，是我的误判断，它事实上是
d5和d6的midas.dll版本的区别，因为凑巧我测试的两台win2000都装了delphi6
其他几台winnt和win98装的是dephi5.为此向关心此问题的先生们致歉
2。目前的结论：
delphi5的midas.dll对TWideStringField最后一位字符变动无法为Delta侦测到
直接用delphi6的midas.dll覆盖winsys目录的文件，可使delphi5正常工作
locate,filter不能在TWideStringField使用问题仍无法解决

多人接受答案了。