Sql server 当我将tinyint列从SQL Server导入Oracle 10g时，为什么会得到负值？

我最近遇到了一个问题，我们运行了一个数据迁移脚本，通过Oracle DBLink将数据从SQL Server移动到Oracle 10g。在我们在Oracle生产环境中运行脚本之前，一切正常。对于SQL Server中定义为tinyint的某些列，我们发现SQL Server数据库中高于127的值现在是负值（比原始值少256）。为什么脚本可以在开发和测试数据库中运行，但不能在生产中运行？

我在问并回答我自己的问题，因为谷歌和StackOverflow无法帮助我解决这个问题，至少在我使用的搜索词方面是如此。当我们开始研究时，我们发现SQL Server将tinyint视为无符号字节（0到255），而Oracle将其视为有符号字节（-128到127）。但是我们导入了一个数字（3）列，这是合适的。出于某种原因，编写数据迁移脚本的人需要使用Oracle的“to_number函数来读取SQL Servertinyint列。因此，如果您在我们的开发和测试环境中运行该查询，那么它在第二列中返回了一些奇怪的字符，但在我们的生产环境中，它在两列中都返回了相同的负数

SELECT to_number("SomeTinyIntColumn"), "SomeTinyIntColumn"
FROM MySQLServerDBLink@mydomain.com

我们最终发现，它在开发和测试环境中工作的原因是因为那里的字符集是UTF-8，但在生产中是西欧的8位字符集：

SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET';
-- Dev and Test: AL32UTF8
-- Prod: WE8ISO8859P1

因此，通过数据库链接将SQL Servertinyint列作为单个UTF-8字符读取并将其转换为OracleNUMBER（3）列似乎是可行的，前提是您对Oracle数据库使用UTF-8字符集。如果DBLink自己处理了转换（使到_数的转换变得不必要），那就太好了，但是它似乎真的不知道如何处理SQL Servertinyint

---

我希望有一天这能帮助别人

我在问和回答我自己的问题，因为谷歌和StackOverflow无法帮助我解决这个问题，至少在我使用的搜索词方面是如此。当我们开始研究时，我们发现SQL Server将tinyint视为无符号字节（0到255），而Oracle将其视为有符号字节（-128到127）。但是我们导入了一个数字（3）列，这是合适的。出于某种原因，编写数据迁移脚本的人需要使用Oracle的“to_number函数来读取SQL Servertinyint列。因此，如果您在我们的开发和测试环境中运行该查询，那么它在第二列中返回了一些奇怪的字符，但在我们的生产环境中，它在两列中都返回了相同的负数

SELECT to_number("SomeTinyIntColumn"), "SomeTinyIntColumn"
FROM MySQLServerDBLink@mydomain.com

我们最终发现，它在开发和测试环境中工作的原因是因为那里的字符集是UTF-8，但在生产中是西欧的8位字符集：

SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET';
-- Dev and Test: AL32UTF8
-- Prod: WE8ISO8859P1

因此，通过数据库链接将SQL Servertinyint列作为单个UTF-8字符读取并将其转换为OracleNUMBER（3）列似乎是可行的，前提是您对Oracle数据库使用UTF-8字符集。如果DBLink自己处理了转换（使到_数的转换变得不必要），那就太好了，但是它似乎真的不知道如何处理SQL Servertinyint

我希望有一天这能帮助别人