Oracle Gateway、SQL Server 和 Application Express 的字符集问题

发布于 2024-08-26 18:52:32 字数 1081 浏览 5 评论 0原文

我正在将数据从使用异构服务(通过 ODBC)访问 SQL Server 上数据的 VMS 上的 Oracle 迁移到通过 Oracle 网关 (dg4msql) 访问 SQL Server 的 AIX 上的 Oracle。 Oracle VMS 数据库使用 WE8ISO8859P1 字符集。 AIX数据库使用WE8MSWIN1252。根据 sp_helpsort,SQL Server 数据库对 Unicode 数据使用“Latin1-General、不区分大小写、区分重音、不区分假名类型、不区分宽度,对于非 Unicode 数据使用代码页 1252 上的 SQL Server 排序顺序 52”。 SQL Server 数据库使用 nchar/nvarchar 或所有字符串列。

在 Application Express 中,某些情况下会出现额外字符,例如 123 显示为 %001%002%003。在 sqlplus 中,一切看起来不错,但如果我使用像 initcap 这样的 Oracle 函数,当我查询 sql server 数据库(使用数据库链接)时,我会看到字符串的每个字母之间出现空格。在旧配置下不会发生这种情况。

我假设问题是 nchar 中有多余的字节,并且 Oracle 中的字符集无法转换它。看来 ODBC 解决方案不支持 nchar,因此必须将它们强制转换回 char,结果显示正常。我只需要查看 sql server 数据,因此我对任何解决方案(例如强制转换)持开放态度,但我还没有找到任何有效的方法。

关于如何处理这个问题有什么想法吗?我是否应该在 Oracle 中使用不同的字符集?如果是,这是否适用于所有模式,因为我只关心其中之一。

更新:我想我可以简化这个问题。 SQL Server 表使用 nchar。 select dump(column) from table returns Typ=1 Len=6: 0,67,0,79,0,88 当值为“COX”时,无论我从远程链接选择到sql server,还是强制转换文字“COX”转换为 nvarchar,或作为 nvarchar 复制到 Oracle 表中。但是,当我选择列本身时,仅当从远程 SQL Server 链接中进行选择时,它才会显示额外的空格。我不明白为什么 dump 会返回相同的东西,但不使用 dump 会显示不同的值。任何帮助表示赞赏。

I am migrating data from a Oracle on VMS that accesses data on SQL Server using heterogeneous services (over ODBC) to Oracle on AIX accessing the SQL Server via Oracle Gateways (dg4msql). The Oracle VMS database used the WE8ISO8859P1 character set. The AIX database uses WE8MSWIN1252. The SQL Server database uses "Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 52 on Code Page 1252 for non-Unicode Data" according to sp_helpsort. The SQL Server databases uses nchar/nvarchar or all string columns.

In Application Express, extra characters are appearing in some cases, for example 123 shows up as %001%002%003. In sqlplus, things look ok but if I use Oracle functions like initcap, I see what appear as spaces between each letter of a string when I query the sql server database (using a database link). This did not occur under the old configuration.

I'm assuming the issue is that an nchar has extra bytes in it and the character set in Oracle can't convert it. It appears that the ODBC solution didn't support nchars so must have just cast them back to char and they showed up ok. I only need to view the sql server data so I'm open to any solution such as casting, but I haven't found anything that works.

Any ideas on how to deal with this? Should I be using a different character set in Oracle and if so, does that apply to all schemas since I only care about one of them.

Update: I think I can simplify this question. SQL Server table uses nchar. select dump(column) from table returns Typ=1 Len=6: 0,67,0,79,0,88 when the value is 'COX' whether I select from a remote link to sql server, cast the literal 'COX' to an nvarchar, or copy into an Oracle table as an nvarchar. But when I select the column itself it appears with extra spaces only when selecting from the remote sql server link. I can't understand why dump would return the same thing but not using dump would show different values. Any help is appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

非要怀念 2024-09-02 18:52:32

Oracle 网关与该特定版本的 SQL Server 上的 nchar 之间不兼容。解决方案是在 SQL Server 端创建视图,将 nchar 转换为 varchar。然后我可以通过网关从视图中进行选择,它可以正确处理字符集。

There is an incompatibility between Oracle Gateways and nchar on that particular version of SQL Server. The solution was to create views on the SQL Server side casting the nchars to varchars. Then I could select from the views via gateways and it handled the character sets correctly.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文