我的一个客户有一个连接到 Oracle 8i 数据库的 SQL Server 2000 数据库。 他们在 SQL Server 2000 数据库中有数十个引用 Oracle 数据库的视图，通常具有简单的语法，例如：
SELECT *
FROM SERVER..DB.TABLE
这些视图（以及引用它们的存储过程）已经工作了多年，没有出现任何问题。 突然，今天早上，其中一些（但不是全部）失败并出现以下错误：
Server: Msg 7330, Level 16, State 2, Procedure SALES_ORDER_HEADERS, Line 7
Could not fetch a row from OLE DB provider 'MSDAORA'.
[OLE/DB provider returned message: ORA-01854: julian date must be between 1 and 5373484]
OLE DB error trace [OLE/DB Provider 'MSDAORA' IRowset::GetNextRows returned 0x80040e07].
当我们使用上面的四部分语法（与视图定义的语法相同）选择数据时，查询成功，没有问题，并且 . 但是，我们无法根据该语法创建视图，无法编辑现有视图（在设计器中），并且无法弄清楚为什么直接查询链接表有效，但通过查询使用它会失败。
我的公司没有构建该系统，我们通常也不会维护它——客户有一个内部开发团队负责处理该系统，但他们要求我们提供故障排除帮助，而我们和他们一样感到困惑，所以我我想我会在这里问。
任何人都知道为什么我们会看到这种行为 - 更重要的是，如何纠正它？ （缺乏升级；目前不是一个选项。）作为临时解决方法，我们发现使用 OPENQUERY 确实有效，但速度当然很慢。 如果可能的话，我们想要一个不涉及 OPENQUERY 的解决方案。
回应评论：视图中没有定义 ORDER BY 。 存储过程中可能有，但我不确定。 （我在发布问题之前大约 20 分钟才第一次看到这个数据库。:)）
I have a client who has a SQL Server 2000 database linked to an Oracle 8i database. They have dozens of views in the SQL Server 2000 database which reference the Oracle database, often with simple syntax such as:
SELECT *
FROM SERVER..DB.TABLE
These views (and the sprocs which reference them) have worked for YEARS without issue. Suddenly, this morning, some (but not all) of them are failing with the following error:
Server: Msg 7330, Level 16, State 2, Procedure SALES_ORDER_HEADERS, Line 7
Could not fetch a row from OLE DB provider 'MSDAORA'.
[OLE/DB provider returned message: ORA-01854: julian date must be between 1 and 5373484]
OLE DB error trace [OLE/DB Provider 'MSDAORA' IRowset::GetNextRows returned 0x80040e07].
When we select data using the four-part syntax above (the same syntax as the view has defined), the queries succeed without issue and the . However, we cannot create a view on that syntax, we cannot edit the existing views (in the designer), and we cannot figure out why directly querying the linked table works, but using it via a query fails.
My company didn't build the system, nor do we generally maintain it -- the client has an internal dev team which works on it, but they asked for our troubleshooting help, and we're just as stumped as they are, so I figured I'd ask here.
Anyone have any clue why we'd see this behavior -- and more importantly, how to correct it? (Short of upgrading; not an option at this point.) As a temporary workaround, we've discovered that using OPENQUERY does function, but it is of course dog slow. We'd like a solution which doesn't involve OPENQUERY, if possible.
In response to the comments: There is no ORDER BY defined in the views. There may be in the sprocs, but I'm not certain. (I just saw this database for the first time about 20 minutes before posting the question. :) )
发布评论
评论（2）
我认为数据发生了多年来未曾发生过的变化。 几年前我发现了类似的东西，我正在开发一个关键的应用程序模块，测试，测试，测试很多用例，一切都很好，在生产的那天引入了未经测试的模式！ 难以置信但却真实！
因为数据的更改导致某种
TO_CHAR(xx, 'J')调用出现错误。 例如，零或负数据。因为很多调用下降可能是所有人共有的基表/列。
操作：
I think a change on data have happened that not happened on years. I found something similar years ago, I was developing a critical application module, testing, testing, testing for a lot of use-cases and all fine, and the day on production a non-tested pattern was introduced! Incredible but true!
Because that change on data something wrong is giving to some kind of
TO_CHAR(xx, 'J')call. For example, zero or negative data.Because a lot of calls are falling may be is a base table/column common to all.
Actions:
您的观点中是否有“ORDER BY”，这可能是原因。
Is there "ORDER BY" in your views, this could be the cause.