Question

我的工作场所有一个由邮政服务提供给我们的.net应用程序，它连接到在同一台机器上运行的oracle数据库，负责注册，存储和打印运输标签。

看到数据库主机等是可配置的，我们询问公司是否可以通过网络使用该应用程序（只需将其复制到另一台机器导致“文字与格式字符串不匹配”错误），我们被告知是“这是不可能的”。我不想拒绝答案，我用反射器戳了一下exe。

与Oracle的v $ sqlarea视图一起，我将错误确定为几个日期比较函数，但我不知道为什么应用程序在原始机器上首先工作。

原始应用程序使用类似于

的查询

SELECT * FROM shipping WHERE date = '2011/03/28' --error

可以轻松修复

SELECT * FROM shipping WHERE to_char(date, 'yyyy/mm/dd') = '2011/03/28'

为什么原始应用程序在不丢失任何错误的情况下工作？当在原始主机上使用该应用程序时，在v $ sqlarea视图中弹出不正确的查询，如果我复制查询并使用其它任何其他方法手动运行它会抛出错误，如果我在任何其他计算机上运行该应用程序它会抛出该错误也是错误，Oracle中是否存在一些即时修改查询的设置，但仅适用于源自本地计算机的查询，同时将原始查询存储在v $ sqlarea中？

Answer 1

如果使用日期，则必须避免基于String.Format的查询生成。使用参数化选择和参数来设置这些值。

    OracleCommand cmd = new OracleCommand("SELECT * FROM shipping WHERE date = :dataParam", connection);
    var param = cmd.Parameters.Add("date", OracleDbType.Date);
    param.Value = DateTime.Now;

它有效，因为格式与开发人员计算机和目标数据库上的日期时间设置相匹配。

换句话说：问题与您尝试提供的错误日期时间格式有关。

Answer 2

这听起来像两个客户端计算机之间的区域设置差异，因为日期的格式化将取决于用于将日期转换为.NET中的字符串的文化，除非应用程序指定文化，否则它将使用运行应用程序的当前登录用户的设置。如果数据库引擎以某种格式期望它们，这显然是一个问题。参数化查询不太可能出现此问题，其中日期参数与查询分开传递，并作为日期数据类型而不是字符串。

Answer 3

这可能是因为服务器上的区域设置。请检查新服务器是否配置了相同的区域设置（EN-GB，EN-US或原始服务器配置使用的任何内容）。

比较类型时奇怪的Oracle + .net行为

3 个答案: