Oracle NUMBER 问题:十进制到 Int64 转换

发布于 2024-07-27 05:20:23 字数 831 浏览 2 评论 0 原文

我们正在开发一个独立的应用程序,将其数据存储在数据库中。 我们使用数据集和表适配器与数据库进行通信。 基本要求之一是应用程序能够使用 SQL Server、Oracle 和 MySQL。 为此,我们在 TA 中进行独立于供应商的查询。 我们使用 ODBC 提供程序。

它对于 SQL Server 和 MySQL 工作得很好,但对于 Oracle 我们遇到了问题。 我们无法克服的问题之一是十进制到 Int64 的转换错误。

Oracle 表使用 NUMBER(38) 作为系统 ID(自动增量字段),它看起来映射到十进制。 然而,由于 SQL Server 和 MySQL 使用 BIGINT,因此我们在 DataSet/TA 中使用 Int64/long。 (请注意,DataSEt TableAdapters 一开始是从 SQL Server 模式自动生成的。)

当从 Oracle 获取 NUMBER 值时,我们会遇到强制转换异常,因为它返回一个十进制对象。

DbCommand getIDcmd = connection.CreateCommand();
getIDcmd.CommandText = "select LAST_ID from SEQUENCE_ID";
sequenceID = (Int64)getIDcmd.ExecuteScalar(); // we get a cast exception here returns decimal 

请注意,我们已尝试降低 Oracle 中的精度数字(例如 NUMBER(10)),正如我们在其他论坛条目中看到的那样,但没有成功。

这是 ODBC 问题吗? 如果我们转移到其他提供商会解决问题吗?

We are developing a standalone application that stores its data in a Database. We use Dataset and TableAdapters for the communication with the Database. One of the basic requirements is the application to be able to use SQL Server, Oracle and MySQL. For this purpose we made the queries in the TAs vendor independent. We use ODBC provider.

It works fine for SQL Server and MySQL, but with Oracle we had problems. One of the problems we can not overcome is the casting error of decimal to Int64.

Oracle tables use NUMBER(38) for system IDs (autoincrement fields) that as it seems are mapped to decimal. However we use Int64/long in the DataSet/TAs since SQL Server and MySQL use BIGINT. (Note that the DataSEt TableAdapters where auto-generated from a SQL Server schema in the beginning.)

We get a cast exception when getting a NUMBER value from Oracle since it returns a decimal object.

DbCommand getIDcmd = connection.CreateCommand();
getIDcmd.CommandText = "select LAST_ID from SEQUENCE_ID";
sequenceID = (Int64)getIDcmd.ExecuteScalar(); // we get a cast exception here returns decimal 

please note that we've tried to lower the precision number in Oracle (e.g. NUMBER(10)) as we've seen with other forum entries but with no luck.

Is this an ODBC problem? If we move to other provider will solve the problem?

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

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

发布评论

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

评论(3

久伴你 2024-08-03 05:20:23

如果 sequence_id 是序列名称,则您的查询在 Oracle 中看起来不正确。 您可以使用如下查询来查询最后给定的 ID:

SELECT last_number FROM all_sequences WHERE sequence_owner=? AND sequence_name=?

强制转换不应该成为问题(如果在 int64 范围内)。

If sequence_id is the name of your sequence your query doesn't look right in Oracle. You would query the last given ID with a query like:

SELECT last_number FROM all_sequences WHERE sequence_owner=? AND sequence_name=?

The cast shouldn't be a problem (if within int64 range).

情何以堪。 2024-08-03 05:20:23

您可以运行它来找出实际返回的类型,然后从那里开始:

System.Windows.Forms.MessageBox.Show(getIDcmd.ExecuteScalar().GetType().ToString());

You could run this to find out what type is actually returned, and then go from there:

System.Windows.Forms.MessageBox.Show(getIDcmd.ExecuteScalar().GetType().ToString());
書生途 2024-08-03 05:20:23

看起来这个查询总是返回一个“小数”。 你可以尝试这个:

sequenceID = Convert.ToInt64(getIDcmd.ExecuteScalar());

我认为你的情况不会出现任何精度损失。

请注意,降低 NUMBER 的精度始终是一个好主意:Int64 映射到 NUMBER(19)
这不会解决您当前的问题,但可能会防止将来出现更多问题。 例如,如果您获得 IDataRecord 包括您的 ID(使用 Microsoft Oracle 提供程序)、对 NUMBER(38) 时,rel="nofollow noreferrer">GetInt64 将失败,而当定义为 NUMBER(19) 时,则成功 (即使该值在正确的范围内)。

It seems like this query will always return a `decimal'. You could try this :

sequenceID = Convert.ToInt64(getIDcmd.ExecuteScalar());

I do not think any loss of precision would occur in your case.

Note that lowering the precision of your NUMBER is always a good idea : Int64 maps to NUMBER(19).
This will not solve your problem at hand, but it may prevent more problems in the future. For instance, if you get an IDataRecord including your id (using the Microsoft Oracle provider), a call to GetInt64 will fail when your column is defined as NUMBER(38) and succeed when defined as NUMBER(19) (even when when the value is in the correct range).

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