我们的虚拟机上有一个SSIS包(假设它是VM1(，我们正在从Oracle源中提取数据。Oracle 中该列的数据类型是 Varchar2，在 SSIS 中，它提取为DT_WSTR数据类型并将数据存储为 NVarchar 列。 当我从不同的虚拟机(假设这是 VM2(打开同一个包时，SSIS 包正在拉取DT_STR数据类型，并且由于 SSIS 包验证阶段的转换错误，包失败。当我单击 Oracle 源 SSIS 包的数据流任务中的列时，我还收到一条警告，该警告粘贴在下面。
警告 - 无法从 OLE DB 检索列代码页信息 供应商。 如果组件支持"默认代码页"属性， 将使用该属性中的代码页。 更改的值 当前字符串代码页值不正确时的属性。 如果 该组件不支持该属性，代码页来自 将使用组件的区域设置 ID。
我们在VM1和VM2上安装了Oracle Java(JDK(和Oracle客户端。 我们的虚拟机上的操作系统是Windows 7，SSIS包在两个虚拟机上都是Visual Studio 2013。
我不得不处理Oracle和SSIS之间的类似数据类型问题。由于SSIS对数据类型如此挑剔，我必须找到一个在Oracle端实现的解决方案。
在我解释我的答案之前，我应该提到我使用了Microsoft的Oracle的Attunity连接器。我强烈建议使用这些连接器，而不是Microsoft和 Oracle 提供的默认连接。
因此，话虽如此，我发现了两种技术，它们似乎可以以正确的编码提取数据。SSIS 在从 Oracle 系统读取和翻译元数据方面确实很糟糕，但显式 CAST 到 VARCHAR2，即使该列已经是VARCHAR2，似乎也足以暗示 SSIS 知道该列将是一个DT_STR类型。在我的所有 Oracle 源任务中，我使用 SQL 命令，而不仅仅是选择表(这是最佳实践(，这允许我将 CAST 添加到查询中。对于VARCHAR2专栏，我会做这样的事情：
SELECT CAST("PO Number" AS VARCHAR2(30)) AS "PONumber" FROM TABLE1
这通常就足够了。但有时不会，因为 Oracle 允许在VARCHAR2列中使用一些奇怪的字符。如果在显式 CAST 列VARCHAR2之后仍[Oracle Source [2345]] Error: OCI error encountered. ORA-29275: partial multibyte character看到错误，这是由于代码页不匹配造成的。要更正它，您可以像这样转换字符串的字符编码：
SELECT CONVERT("PO Number",'AL32UTF8','WE8MSWIN1252') AS "PONumber" FROM TABLE1
AL32UTF8是 Oracle 使用的默认 (Unicode( 编码，WE8MSWIN1252是 Windows 系统使用的默认 (ASCII 1252( 编码。