Delphi TBytesField - 如何正确查看文本 - 来源是 HIT OLEDB AS400
我们正在通过 HIT OLEDB 和 HIT ODBC 连接到多成员 AS400 iSeries 表。
您可以通过别名连接到该表以访问特定的多成员。我们以这种方式在 AS400 上创建别名：
CREATE ALIAS aliasname FOR table(membername)
然后我们可以这样查询表的每个成员：
SELECT * FROM aliasname
我们首先在 Delphi6 中对此进行测试，但稍后将其移至 D2010
我们在 AS400 上使用 HIT OLEDB。
我们从表中提取记录，该字段被视为 tBytesField。我也尝试过 ODBC 驱动程序，它也视为 tBytesField。
我可以直接在 AS400 上查询数据并查看可读文本。我可以使用 iSeries 导航工具并查看可读文本。
然而，当我通过 HIT OLEDB 或 HIT ODBC 将其带到 Delphi 客户端并尝试通过 asString 查看时，我只看到不可读的文本..像这样：
ñðð@ðõñðððñ÷@õôððõñòøóóöøñðÂÁÕÒ@ÖÆ@ÁÔÅÙÉà@@@@@@@@@ÈÙÉâãæÁðòñè@ÔK@k@ÉÕíK@@@@@@@@@ç
我把上面的文字搞乱了，但那是显示的字符类型向上。
当我在 D2010 中进行测试时，文本看起来像日文或中文字符，但如果我显示为 AnsiString 那么它看起来就像在 Delphi 6 中所做的那样。
我认为这可能与代码页或字符集有关，但是我在这方面没有经验，所以如果有相关的话，这对我来说是新的。当我查看 AS400 上的编码字符集时，它设置为 65535。
我需要做什么才能使该文本可读？
我们确实有一个第三方组件（Delphi400），它可以使事情以更原生的 AS400 方式运行。当我使用它的 AS400 连接和 AS400 查询组件时，它将该字段显示为 tStringField 并且显示得很好。但我们正在逐步淘汰该产品（出于多种原因），并且非常希望 OLEDB 能够与 ADO 组件一起工作。
只是为了澄清，对于我们使用的许多其他表，带有 tADOQuery 的 HIT OLEDB 确实有一些字段显示为 tStringFields...不知道为什么在这种情况下它显示为 tBytesField。我不是 AS400 专家，但是查看 AS400 上的字段定义，显示为 tBytesField 的字段定义与显示为 tStringFields 的字段定义看起来相同...但一定有区别。也许是因为是多人成员？
那么...有人对如何获取可读的正确字符串数据有任何指导吗？
如果您需要更多信息，请询问。
格雷格
We are connecting to a multi-member AS400 iSeries table via HIT OLEDB and HIT ODBC.
You connect to this table via an alias to access a specific multi-member. We create the alias on the AS400 this way:
CREATE ALIAS aliasname FOR table(membername)
We can then query each member of the table this way:
SELECT * FROM aliasname
We are testing this in Delphi6 first, but will move it to D2010 later
We are using HIT OLEDB for the AS400.
We are pulling down records from a table and the field is being seen as a tBytesField. I have also tried ODBC driver and it sees as tBytesField as well.
Directly on the AS400 I can query the data and see readable text. I can use the iSeries Navigation tool and see readable text as well.
However when I bring it down to the Delphi client via the HIT OLEDB or HIT ODBC and try to view via asString then I just see unreadable text.. something like this:
ñðð@ðõñððððñ÷@õôððõñòøóóöøñðÂÁÕÒ@ÖÆ@ÁÔÅÙÉÃÁ@@@@@@@@ÂÈÙÉâãæÁðòñè@ÔK@k@ÉÕÃK@@@@@@@@@ç
I jumbled up the text above, but that is the character types that show up.
When I did a test in D2010 the text looks like japanse or chinese characters, but if I display as AnsiString then it looks like what it does in Delphi 6.
I am thinking this may have something to do with code pages or character sets, but I have no experience in this are so it is new to me if it is related. When I look at the Coded Character Set on the AS400 it is set to 65535.
What do I need to do to make this text readable?
We do have a third party component (Delphi400) that makes things behave in a more native AS400 manner. When I use its AS400 connection and AS400 query components it shows the field as a tStringField and displays just fine. BUT we are phasing out this product (for a number of reasons) and would really like the OLEDB with the ADO components work.
Just for clarification the HIT OLEDB with tADOQuery do have some fields showing as tStringFields for many of the other tables we use... not sure why it is showing as a tBytesField in this case. I am not an AS400 expert, but looking at the field definititions on the AS400 the ones showing up as tBytesField look the same as the ones showing up as tStringFields... but there must be a difference. Maybe due to being a multi-member?
So... does anyone have any guidance on how to get the correct string data that is readable?
If you need more info please ask.
Greg
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一个问题是您的客户端不知道它应该将数据从 EBCDIC 转换为 ASCII，因为服务器表上的 CCSID 设置不正确。
CCSID 65535 应该意味着该字段包含二进制数据。您的客户端不知道该列包含 EBCDIC 编码字符串，因此不会尝试对其进行转换。
在我的服务器上，所有字符字段的 CCSID 均为 37，即 EBCDIC。
One problem is that your client doesn't know that it ought to convert the data from EBCDIC to ASCII because the CCSID on the server's table was set incorrectly.
A CCSID of 65535 is supposed to mean that the field contains binary data. Your client doesn't know that the column contains an EBCDIC encoded string, and therefore doesn't try to convert it.
On my servers, all of our character fields have a CCSID of 37, which is EBCDIC.
我找到了答案......在 HIT ODBC 400 和 HIT OLEDB 400 上都有一个名为“Convert CCSID 65535=True”的属性，或者在 OLEDB UDL 中它看起来像“Binary Characters=True”。
不知道我是怎么错过这些的，但这确实成功了！
感谢您的反馈。
I found the answer... on both HIT ODBC 400 and HIT OLEDB 400 there is a property called: "Convert CCSID 65535=True" or in the OLEDB UDL it looks like "Binary Characters=True".
Don't know how I missed those, but that did the trick!
Thanks for the feedback.