2

我们的 .NET 应用程序存在 x 文件问题。或者，更确切地说，混合 Win32 和 .NET 应用程序。

当它试图与 Oracle 通信时，它就死了。消失。向着天空中的黑色大虚空而去。没有事件日志消息，没有异常，没有任何东西。

如果我们只是要求应用程序与 MS SQL Server 对话，其效果是将 OracleConnection 和相关类的使用替换为 SqlConnection 和相关类，它会按预期工作。

今天我们取得了突破。

出于某种原因，一位客户发现通过将所有应用程序文件放在他桌面上的一个目录中，Oracle 也可以正常工作。将目录向下移动到驱动器的根目录，或者在 C:\Temp 或者，好吧，大约一点，使崩溃再次出现。

基本上，如果从桌面目录运行，应用程序可以 100% 重现，如果从根目录运行，应用程序会失败。

今天我们发现重要的区别在于目录名称中是否有空格。

因此，这些目录将起作用：

C:\Program Files\AppDir\Executable.exe
C:\Temp Lemp\AppDir\Executable.exe
C:\Documents and Settings\someuser\Desktop\AppDir\Executable.exe

而这些不会：

C:\CompanyName\AppDir\Executable.exe
C:\Programfiler\AppDir\Executable.exe      <-- Program Files in norwegian
C:\Temp\AppDir\Executable.exe

我希望读到这篇文章的人看到过类似的行为并且有“啊哈，你需要在 oracle glitz 驱动程序配置上调整 frob”或类似的东西。

任何人？

跟进#1：好的，我现在已经处理了 procmon 输出，这两个文件都是从我点击按钮尝试打开触发级联故障的窗口时开始的，我注意到它们大部分都在跟踪，有一些小的差异靠近两个文件的顶部，并且它们跟踪很长的路要走。

但是，当一个运行失败时，另一个会继续运行，日志输出的下几行如下：

ReadFile C:\oracle\product\10.2.0\db_1\BIN\orageneric10.dll    SUCCESS    Offset: 274 432, Length: 32 768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
ReadFile C:\oracle\product\10.2.0\db_1\BIN\orageneric10.dll    SUCCESS    Offset: 233 472, Length: 32 768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O

在此之后，工作运行继续执行，另一个在线程关闭和应用程序关闭之前触摸 mscorwks.dll 文件几次。因此，失败的运行不会触及上述文件。

跟进#2：我想我会尝试升级 oracle 客户端驱动程序，但 10.2.0.1 显然是 Windows 2003 服务器和 XP 客户端可用的最高版本。

跟进#3：嗯，我们最终得到了一个黑盒解决方案。基本上我们发现问题与XPO和 Oracle 有关。XPO 有一个它管理的系统表，称为 XPObjectType，它包含三列：Oid、TypeName 和 AssemblyName。由于 Oracle 在我们与之交谈的数据库中的配置方式，列名是 OID、TYPENAME 和 ASSEMBLYNAME。这通常不会成为问题，除了 XPO 直接与架构信息对话并检查表是否具有正确的列名，并且 XPO 不处理大小写差异，因此它会看到一个 XPObjectType 表，其中包含三个未知列并且没有它期望的那些。

XPO 现在究竟做了什么我真的不知道，但是如果我删除了这个表，并用正确的大小写重新创建它，在所有列名周围使用双引号来正确区分大小写，问题就不会出现。

文件夹名称中的空格到底是从哪里来的，我仍然不知道，但这个问题有两个层次：

  1. 阻止应用程序在我们的客户处崩溃，短期解决方案
  2. 修复bug，长期解决方案

现在第 1 层已解决，第 2 层将暂时放回队列并优先处理。无论如何，我们的数据层都面临着一些更大的变化，所以这可能不是我们需要解决的问题，至少如果我们所有的 Oracle 客户都验证表修复确实解决了问题的话。

我会接受Dave Markle的回答，因为尽管 Process Monitor（文件监视器的老大哥）实际上并没有查明问题，但我能够使用它来确定在 XPO 建立的用户代码中的断点之后对该表的查询，直到应用程序关闭的所有条目都被记录后才发生 I/O，这让我相信这张表是罪魁祸首，或者至少以某种方式影响了问题。

如果我设法找到真正的原因，我会更新帖子。

4

4 回答 4

3

这就是我要做的。首先，三重检查您是否看到了您认为您正在看到的行为。通过不使用 System.IO.Path 连接路径，我可以看到这种情况发生了相反的情况，但不像你看到的那样。三重检查文件权限是否有意义。

接下来，从 MS 下载Filemon并观察在您的程序遇到这些问题时文件系统上发生的情况。您可以过滤掉特定的文件活动（例如，删除您的防病毒文件活动），以使您在执行此操作时看起来更干净。使用 FileMon 查找程序的成功案例和错误案例的文件访问错误。这应该指出您正在访问什么文件并导致问题。例如，如果您在FILE_NOT_FOUND访问无意义的文件名时看到错误，您可以确信您或供应商做错了什么，可能导致您的问题......

于 2008-10-27T11:54:28.637 回答
1

您可能应该看看是否可以使用仅尝试打开与 Oracle 的连接的简单应用程序来重现该问题。这样，您可以 100% 确定问题出在 OracleConnection 或 Oracle 驱动程序上，而不是您自己的代码上。

于 2008-10-27T14:07:36.540 回答
0

您应该为此获得毅力奖章！

“我真的不知道 XPO 现在到底做了什么，但如果我删除了这个表，并用正确的大小写重新创建它，在所有列名周围使用双引号来正确区分大小写，问题就不会出现。

文件夹名称中的空格到底是从哪里来的，我还是不知道”

我在名称中使用空格时遇到的问题是，它们通常将空格前的位解释为名称，将其余位解释为参数。如果是这种情况，那么使用纯名称它可以看到“C\Temp”并且它是一个目录。使用带间隔的名称，它会获取“C:\Program Files”，查找“C:\Program”，但它不存在。例如，覆盖“C:\Temp”会失败，但会成功写入“C:\Program”。如果有一个名为“C:\Program”的文件或目录，想知道它是否仍然会因“C:\Program Files”而失败

于 2009-09-18T00:39:22.380 回答
0

我怀疑预言机客户端是诚实的。有一个令人沮丧的性质相似的问题。

如果我们安装在 64 位机器上，即使应用程序是 32 位，客户端在连接到 oracle 时也会在启动时停止。我们最终追查到某个 oracle 客户端（Ora 10 路径中的括号有问题，因此在程序文件下运行的程序将在程序文件（x86）下运行的程序导致崩溃。更新机器以使用 11G客户端解决了这个问题，但也有一些不能直接使用的补丁可以从metalink获得。在你的情况下，奇怪的是你没有例外，但是将应用程序移动到新文件夹的行为以类似的方式解决了这个问题，所以它可能是相关的。

ORA-12154: TNS: 无法解析指定的连接标识符或 ORA-6413: 连接未打开。

有用的链接http://blogs.msdn.com/debarchan/archive/2009/02/04/good-old-connectivity-issue.aspx

下面来自 Metalink 的详细信息。

Metalink 错误 3807408 无法在用户名中使用引号对用户进行外部身份验证

说明 如果外部验证的用户名包含“(',')' 或 '='，则无法验证用户。此外，如果程序名称/路径包含这些字符，则可能无法连接。例如：安装在目录“C:\Program Files (x86)”中的 Windows 客户端无法与 ORA-12154 连接：TNS：无法解析指定的连接标识符

此问题的标志是网络跟踪（级别 16）显示问题字符替换为“？” 在跟踪。

解决方法 对于身份验证问题：更改用户名，或不对这些用户使用远程操作系统身份验证

对于程序/目录问题：更改程序/目录名称

于 2010-05-04T20:13:24.297 回答